Automated safe secure techniques for eliminating undefined behavior in computer software

ABSTRACT

Automated (e.g., compiler implemented) techniques provide safe secure software development. One exemplary illustrative implementation addresses undefined behavior in the C and C++ programming languages.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation-in-part of application Ser. No.10/964,830 filed Oct. 15, 2004, which application iscontinuation/substitution for application Ser. No. 10/941,023 filed Sep.15, 2004, which claims the benefit of Provisional Application No.60/502,620, filed Sep. 15, 2003 and Provisional Application No.60/511,649, filed Oct. 17, 2003. The entire contents of theseapplications are incorporated by reference.

FIELD

The technology herein relates to the design and construction ofcompilers which implement control flow analysis, data flow analysis,optimizations (including the type-based aliasing requirements),definite-assignment analysis, and the ANSI/ISO standards for the subjectlanguages, and to software testing and verification. In more detail, thetechnology herein relates to safe secure software compiling techniques,and more particularly to a “blueprint” for methods, techniques andsystems that can be used to create a particular exemplary implementationfor use with the C and C++ programming languages which satisfiesspecified criteria for safety and security.

BACKGROUND AND SUMMARY

Most computer users have experienced times when their computer seeminglyhas “lost its mind” and starts behaving in seemingly unexplainable ways.For example, sometimes we command the computer to do so mething—butinstead of doing what we ask, the computer “stops responding” and needsto be “rebooted” (e.g., turned off and back on again). This process canwaste significant time while the computer restarts. Work product issometimes lost—frustrating users to no end.

Ultimately, most such problems are caused by programming errors(sometimes called “bugs”). As computer programs become increasinglycomplex, it is more difficult for the people writing the computer codeto take into account every possible condition that the computer programmay encounter. Unfortunately, a computer program will “break” if thecode encounters an undefined condition it does not “know” how to handle.This can cause serious problems. Consider for example if the softwarecontrols an airplane autopilot, a missile guidance system or a hospitallife support system.

Another range of problems relates to attackers taking advantage ofundefined computer program behavior to do harm. Several of the undefinedbehaviors of C and C++ have received much attention in the popular pressas well as technical journals, because their effects have inflictedbillions of dollars of damage in the USA and worldwide. In particular,the “buffer overflow” (also known as “buffer overrun”) and “null pointerindirection” behaviors have created vulnerabilities in widely-usedsoftware from many different vendors. This problem of buffer overflowsis no longer an obscure technical topic. This is the vulnerabilitythrough which most worms and viruses attack. The worldwide total costsdue to malicious hacker attacks during 2002 have been estimated to bebetween 40 and 50 billion USD; costs for 2003 were estimated between 120and 150 billion USD. See e.g., David Berlind, “Ex-cybersecurity czarClarke issues gbomy report card” (ZDNet TechUpdate Oct. 22, 2003).

An international standard has been developed for the programminglanguage C, which is designated ISO/IEC 9899:2002(E) (“the ISO C99standard”, i.e., “the C standard”). Similarly, an international standardhas been developed for the programming language C++, which is designatedISO/IEC 14882:2003(E) (“the ISO C++ standard”, i.e., “the C++standard”). The previous international standard for the programminglanguage C was designated ISO/IEC 9899:1990(E) (“the ISO C90 standard”).Each of these standards defines certain situations using the category of“undefined behavior”. The C Standard contains the following definition:“3.4.3 undefined behavior: behavior, upon use of a nonportable orerroneous program construct or of erroneous data, for which thisInternational Standard imposes no requirements. NOTE Possible undefinedbehavior ranges from ignoring the situation completely withunpredictable results, to behaving during translation or programexecution in a documented manner characteristic of the environment (withor without the issuance of a diagnostic message), to terminating atranslation or execution (with the issuance of a diagnostic message).”The C++ Standard contains a similar definition: “1.3.12 undefinedbehavior: behavior, such as might arise upon use of an erroneous programconstruct or erroneous data, for which this International Standardimposes no requirements. Undefined behavior may also be expected whenthis International Standard omits the description of any explicitdefinition of behavior. [Note: permissible undefined behavior rangesfrom ignoring the situation completely with unpredictable results, tobehaving during translation or program execution in a documented mannercharacteristic of the environment (with or without the issuance of adiagnostic message), to terminating a translation or execution (with theissuance of a diagnostic message). Many erroneous program constructs donot engender undefined behavior; they are required to be diagnosed.]”

Some undefined behaviors can be eliminated by using techniques alreadyknown in the current art. The next sections will describe some exemplarysuch techniques.

Design-Time Choices [dt]

Several undefined behaviors can be addressed by design choices; theseundefined behaviors are marked with “dt” in column one of the tablebelow. In general, the guiding principle behind these design choices isthat non-portable behavior is generally not as bad as undefined (unsafe)behavior. For example; byte-ordering affects the numeric value ofresults, but so long as address bounds are not exceeded, byte-orderedinteger values produce something well-defined on each hardware platform.

-   -   a. The representation of a null pointer can be all-bits-zero.    -   b. The representation of pointers can be binary two's-complement        with non-signaling wraparound.    -   c. Every possible binary value can be interpreted as a valid        data element. Every data value can be fetched safely; in that        sense, there are no “trap representations”. A “trap” can result        if fetch or store of an invalid pointer is attempted, but not        upon calculation or comparison of addresses. Therefore,        uninitialized memory can be fetched safely. An incompletely-read        buffer after a read error (such as in Standard C subclauses        7.19.7.2, 7.19.7.7, 7.24.3.2, etc) still contains data bytes        which will not cause traps upon fetch. If any hardware datatype        does contain “trap representations” at the assembler-code level,        then the implementation can catch any such trap (invisibly to        the C/C++ code) and replace the value in the register with a        value that conforms to Safe Secure design-time choices (such as        a “quiet NaN” for floating—point values).    -   d. A request to the allocation functions malloc and calloc to        allocate zero bytes can cause the allocation of the smallest        non-zero allocation.    -   e. If the number-of-elements argument is zero, string and        wide-string and sorting and searching functions can do-nothing        gracefully.    -   f. The sorting and searching functions can be limited to no more        than an implementation-defined maximum number of iterations.    -   g. The algorithms for converting between wide characters and        (narrow) characters can produce deterministic results for all        inputs, in either direction. Therefore, when a stream was        written wide-oriented and read byte-oriented, the behavior can        be implementation-defined and not undefined, and similarly for a        stream written byte-oriented and read wide-oriented.    -   h. The wcstok function can be implemented so that, if it is        invoked with a null pointer, then the pointer argument need not        be equal to the pointer argument of the previous, but can        require only that the “saved” pointer must designate some        non-const array of characters, null-terminated.    -   i. The wcstok and strtok functions can be implemented so that,        if the first invocation passes a null pointer, the function can        ignore it and return a null pointer; alternatively, the function        can invoke a safe termination such as ss_unwind (see below).    -   j. The compiler can be configured for each accompanying set of        Standard C++ Library functions, so that several undefined        behaviors can be eliminated by design-time choices.    -   k. The compiler can issue a fatal diagnostic for all visible        attempts to modify a string literal. When a string literal has        become the target of a pointer, the methods shown in this        Application will ensure that the pointer will not be used to        modify storage outside the bounds of the string literal's array.        In-bound modifications made to that array will exhibit        well-defined behavior according to the underlying machine model:        if the array has been allocated in a ROM or write-protected        segment, the attempt to write will either cause an ss-unwind or        a no-op.    -   l. [reserved—no L]    -   m. The allocation functions can always return one minimum-sized        storage allocation in response to the request to allocate zero        bytes. The Requirement of any subsequent fetch-or-store through        that pointer must be met, regarding both range and type.    -   n. Each static variable can be accompanied by an        initialization-guard flag. Upon entry to the construction or        destruction of a block-scope, file-scope, or dynamically-loaded        object with static storage duration, the flag is set. This flag        is cleared when construction or destruction is complete.    -   o. The implementation can analyze the code of each C++ special        function (constructor and destructor) to determine whether any        undefined behavior would result from re-entering that function        before a prior invocation has returned. If so, the generated        code for that function shall test the initialization-guard flag        to prevent such re-entry.    -   p. The implementation can provide a dummy function to be invoked        any time the user program erroneously calls a pure virtual C++        function. In Debug mode, an “unwind” (such as ss_unwind) can be        invoked, and the implementation may throw an exception of an        implementation-defined type. In non-Debug mode, a no-op can be        performed.    -   q. The implementation can provide an API which will incorporate        the functionality of the C atexit function, along with extra        information to allow the execution of destructors for static        objects in the reverse order of construction, even including        dynamic libraries.

In this Application, the undefined behaviors of C and C++ are itemizedin several tables. In each table, the first column is headed “SSM#” andrepresents the “Safe-Secure Method Name”; for example, in the followingtable, each entry in column one specifies “dt” for the “Design-timechoices [dt]” subsection of this Application. The second column isheaded either “C-Std #” for “C Standard Number” or “C++−Std #” for “C++Standard Number”, i.e., the subclause number of the ISO/IEC standard forC or C++. The third column is headed “Description” and describes thespecific undefined behavior.

The methods shown in this section can be used to eliminate the followingundefined behaviors:

SSM# Description C-Std# dt c7.19.2 A byte input, coutput function isapplied to a wide-oriented stream, or a wide character input, coutputfunction is applied to a byte-oriented stream dt c7.13.2.1 After alongjmp, there is an attempt to access the value of an object ofautomatic storage class with non-volatile-qualified type, . . . dtc7.13.2.1 . . . local to the function containing the invocation of thecorresponding setjmp macro, that was changed between the setjmpinvocation and longjmp call dt c6.5.16.1 An object containing nopointers is assigned to an inexactly overlapping object or to an exactlyoverlapping object with incompatible type dt c6.5.16.1 An objectcontaining pointers is assigned to an inexactly overlapping object or toan exactly overlapping object with incompatible type dt c7.14.1.1 Asignal occurs other than as the result of calling the abort or raisefunction, and the signal handler refers to an object with static storageduration other than by assigning a value to an object declared asvolatile sig_atomic_t, or . . . dt c7.14.1.1 . . . calls any function inthe standard library other than the abort function, the_Exit function,or the signal function (for the same signal number) dt c6.2.6.1 A traprepresentation is produced by a side effect that modifies any part ofthe object using an lvalue expression that does not have character typedt c6.2.6.1 A trap representation is read by an lvalue expression thatdoes not have character type dt c6.3.1.4 Conversion to or from aninteger type produces a value outside the range that can be representeddt c6.3.1.5 Demotion of one real floating type to another produces avalue outside the range that can be represented dt c6.4.5 The programattempts to modify a string literal dt c6.5 Between two sequence points,an object is modified more than once, or is modified and the prior valueis read other than to determine the value to be stored dt c6.5.6 Theresult of subtracting two pointers is not representable in an object oftype p trdiff_t dt c6.5.7 An expression having signed promoted type isleft-shifted and either the value of the expression is negative or theresult of shifting would be not be representable in the promoted type dtc6.5.7 An expression is shifted by a negative number or by an amountgreater than or equal to the width of the promoted expression dt c6.5accAn object has its stored value accessed other than by an lvalue of anallowable type dt c6.7.3 An attempt is made to modify an object definedwith a const- qualified type through use of an lvalue withnon-const-qualified type dt c6.7.3 An attempt is made to refer to anobject defined with a volatile- qualified type through use of an lvaluewith non-volatile-qualified type dt c6.7.8 The value of an unnamedmember of a structure or union is used dt c6.9.1 The } that terminates afunction is reached, and the value of the function call is used by thecaller dt c7.11.1.1 The program modifies the string pointed to by thevalue returned by the setlocale function dt c7.11.2.1 The programmodifies the structure pointed to by the value returned by thelocaleconv function dt c7.13.2.1 The longjmp function is invoked torestore a nonexistent environment dt c7.14.1.1 A signal handler returnswhen the signal corresponded to a computational exception dt c7.14.1.1 Asignal is generated by an asynchronous signal handler dt c7.14.1.1 Asignal occurs as the result of calling the abort or raise function, andthe signal handler calls the raise function dt c7.14.1.1 The value oferrno is referred to after a signal occurred other than as the result ofcalling the abort or raise function and the corresponding signal handlerobtained a SIG_ERR return from a call to the signal function dtc7.19.5.2 The stream for the fflush function points to an input streamor to an update stream in which the most recent operation was input dtc7.19.6.1, A % conversion specifier is encountered by one of theformatted c7.19.6.2, input, coutput functions, but the completeconversion specification c7.24.2.1, is not exactly %% c7.24.2.2 dtc7.19.6.2, A c, s, or [conversion specifier with an l qualifier isencountered c7.24.2.2 by one of the formatted input functions, but theinput is not a valid c7.19.7.2, multibyte character sequence that beginsin the initial shift state c7.19.7.7, dt c7.24.3.2 The contents of thearray supplied in a call to the fgets, gets, or fgetws function are usedafter a read error occurred dt c7.19.8.1 A partial element read by acall to the fread function is used dt c7.19.8.1, The file positionindicator for a stream is used after an error c7.19.8.2 occurred duringa call to the fread or fwrite function dt c7.20.3 A non-null pointerreturned by a call to the calloc, malloc, or realloc function with azero requested size is used to access an object dt c7.20.3.3 The valueof the object allocated by the malloc function is used dt c7.20.3.4 Thevalue of any bytes in a new object allocated by the realloc functionbeyond the size of the old object are used dt c7.20.4.5, The string setup by the getenv or strerror function is modified by c7.21.6.2 theprogram dt c7.20.5 The comparison function called by a searching orsorting utility function alters the contents of the array being searchedor sorted, or returns ordering values inconsistently dt c7.20.5.1 Thearray being searched by the bsearch function does not have its elementsin proper order C++-Std# dt 2.13.4 para 2 Attempting to modify a stringliteral dt 3.6.1 para 4 std::exit is called to end a program during thedestruction of an object with static storage duration. dt 3.7.3.1 para 2Dereferencing a pointer returned as a request for zero size dt 4.8 para1 Floating-point conversion, source value out-of-range of target dt 4.9para 1 Floating-point to integer conversion, source value out-of-rangeof target dt 5.3.4 para 6 In a direct new-declarator the expressionevaluates to a negative value dt 6.7 para 4 Control re-entersinitialization recursively. dt 14.6.4.2 para 1 Function lookup wouldhave been ill-formed, or better match, if all translation units wereconsidered. dt 17.4.3.6 para 2 A replacement function that does notimplement Required behavior dt 17.4.3.6 para 2 A handler function thatdoes not implement Required behavior dt 17.4.3.6 para 2 A templateargument does not implement Requirements dt 17.4.3.6 para 2 Replacementfunction, handler function, or dtor throws an exception (unlessspecifically allowed) dt 18.1 para 5 Taking offsetof of a non-POD typedt 26.2 para 3 Result of function is not mathematically defined, or notin range of representable values dt 27.4.2.7 para 1 ios_base object isdestroyed before basic_ios::init initializes the members dt 27.4.4 para2 error vatue P(O(−1)) is used as arg to . . . member that acceptstraits::pos type dt 27.4.4.1 para 2 basic ios object is destroyed beforeinit initializes the members dt 27.7.1.3 para 14 the sp arg to seekposhas not been obtained by previous successful call to a positioningfunctionText Streams and Character Representations [code]

An exemplary implementation can use a specific choice among theUnix/POSIX/Linux encoding of text files (with LF line terminators), theMacintosh encoding of text files (with CR line terminators), or theMicrosoft Windows encoding of text files (with CR/LF line terminators).All mbstate_t conversions can produce implementation-defined results,even after changing the LC_CTYPE category.

An implementation can make truncated-result behavior well-defined instrxfrm, strftime, wcsxfrm, or wcsftime.

The multibyte functions can behave gracefully when given a sequence notin the initial shift state, or when given any mbstate_t object.

The wide-character classifying and conversion functions can bewell-defined for any wint_t input and for any LC_CTYPE setting.

The Standard C++ Library can be designed to provide a valid result foroperator* at end-of-stream.

The methods shown in this section can be used to eliminate the followingundefined behaviors:

SSM# C-Std# Description code c7.19.2 Use is made of any portion of afile beyond the most recent wide character written to a wide-orientedstream code c7.19.6.1, c7.19.6.2, The format in a call to one of thec7.23.3.5, c7.24.2.1, formatted input, coutput functions or to thec7.24.2.2, c7.24.5.1 strftime or wcsftime function is not a validmultibyte character sequence that begins and ends in its initial shiftstate

SSM# C++-Std# Description code 24.5.3 para 2 The result of operator* onend-of-streamSecure Library [slib]

The secure (or “safer”) library enhancements being standardized byISO/IEC JTC 1 SC22/WG14 will eliminate many opportunities for undefinedbehavior (see www.open-std.org/jtc1/sc22/wg14/www/docs/n1093.pdf).Furthermore, if a formatted I/O function produces more than INT_MAXchars of output, then it can return INT_MAX.

The methods shown in this section can be used to eliminate the followingundefined behaviors:

SSM# C-Std# Description slib c7.19.6.1, c7.19.6.3, The number ofcharacters transmitted c7.19.6.8, c7.19.6.10 by a formatted outputfunction is greater than INT_MAXSs_Unwind [longj]

The longjmp function (and any other functions which “unwind” the stack),can check whether execution of atexit-registered functions has started.If so, one of the following implementation-defined actions can beperformed: cause a return from the function that invoked the unwind orlongjmp function, invoke an “extreme exit” cleanup function; or invokethe abort function. Optionally, at the point of catching the ss_unwind,a system sanity check can be performed before continuing or re-starting.

The methods shown in this section can be used to eliminate the followingundefined behavior:

SSM# Description C-Std# longj c7.20.4.3 During the call to a functionregistered with the atexit function, a call is made to the longjmpfunction that would terminate the call to the registered functionC++-Std# longj 18.7 para 4 If autos would be destroyed by thrownexception transferring to destination, longjmp to that destination hasundefined behaviorSpecial Behavior of Atexit Functions [atex]

The exit function can check whether execution of the exit function haspreviously started. If so, one of the following implementation-definedactions can be performed: invoke an “extreme exit” cleanup function; orinvoke the abort function.

The methods shown in this section can be used to eliminate the followingundefined behavior:

SSM# C-Std# Description atex c7.20.4.3 The program executes more thanone call to the exit functionArithmetic Exceptions [exc]

If at compile-time the right operand of division or remainder is zero, afatal diagnostic message can be produced. In Debug mode, if at run-timethe right operand of division or remainder is zero, an “unwind” (such asss_unwind) can be invoked, and the implementation may throw an exceptionof an implementation-defined type. In non-Debug mode, if at run-time theright operand of division or remainder is zero, the result can be themaximum value of the result type, which for a floating-point type may bean infinity.

If at compile-time the left operand of division or remainder is themaximum negative value of its type and the right operand is −1, a fataldiagnostic message can be produced. In Debug mode, if at run-time theleft operand of division or remainder is the maximum negative value ofits type and the right operand is −1, an “unwind” (such as ss_unwind)can be invoked, and the implementation may throw an exception of animplementation-defined type. In non-Debug mode, if at run-time the leftoperand of division or remainder is the maximum negative value of itstype and the right operand is −1, the result can be the maximum value ofthe result type.

If at compile-time the result of an integral arithmetic operation is toolarge for its type, a fatal diagnostic message can be produced. In Debugmode, if at run-time the result of an integral arithmetic operation istoo large for its type, an “unwind” (such as ss_unwind) can be invoked,and the implementation may throw an exception of animplementation-defined type. In non-Debug mode, if at run-time theresult of an integral arithmetic operation is too large for its type,the result can be the value of the twos-complement operation withwrap-around.

The methods shown in this section can be used to eliminate the followingundefined behaviors:

SSM# C-Std# Description exc c6.5.5 The value of the second operand ofthe / or % operator is zero exc c6.5exc An exceptional condition occursduring the evaluation of an expressionControl of Dangling Pointers [dang]

One category of undefined behavior arises from accessing freed storage.Furthermore, each freed pointer must previously have been allocated.

These undefined behaviors can be eliminated by use of garbagecollection, either conservative (see, e.g., Hans-J Boehm, “A GarbageCollector for C and C++”,(http://www.hpl.hp.com/personal/Hans_Boehm/gc/)) or accurate (see e.g.,Fergus Henderson, “Accurate Garbage Collection in an UncooperativeEnvironment”, ISMM'02, June 2021, 2002, Berlin, Germany, ACM1581135394/02/0006), supplemented with the following special treatmentof pointers to terminated stack frames. Directly assigning an address inthe current function's stack frame to a longer-life pointer can beprohibited. Define a pointer-retainer function as a function whichstores a pointer argument in heap or static storage. Passing a pointerto stack to a pointer-retainer function can be prohibited. (Whateverdata resides in the stack can be copied to heap or to static, to avoidthe prohibition.)

Memory that could contain pointers can be initialized to zeroes.Therefore, (as in Boehm conservative garbage-collection) mallocallocates space that might have pointers in it, so the space iszero-filled. There can be anew attribute to describe a state named e.g“not_ptrs” for any storage which is guaranteed not to contain pointers,and a different version of malloc can be used for such storage(equivalent to GC_malloc_atomic in the Boehm library):

void * malloc_not_ptrs(size_t n);

If storage with the not_ptrs attribute is cast to pointer-to-anything,then a fatal diagnostic message can be produced. The not_ptrs attributecan be removed from any storage by assigning zero to the bytes of thestorage; a byte-oriented alias is mandatory (char, or unsigned char, ora library function such as memset which modifies the bytes of memory).

An alternative method for prevention of dangling pointers is known (seee.g., Todd M. Austin et al., Efficient Detection of All Pointer andArray Access Errors, Proceedings of the ACM SIGPLAN '94 Conference onProgramming Language Design and Implementation, June 1994), which is afeasible solution for an implementation which operates entirely in BSAFEmode (see below,

The methods shown in this section can be used to eliminate the followingundefined behaviors:

SSM# C-Std# Description dang c7.20.3.2, The pointer argument to the freeor realloc function c7.20.3.4 does not match a pointer earlier returnedby calloc, malloc, or realloc, or the space has been deallocated by acall to free or realloc dang c7.20.3 The value of a pointer that refersto space deallocated by a call to the free or realloc function is useddang c6.2.4 An object is referred to outside of its lifetime dang c6.2.4The value of a pointer to an object whose lifetime has ended is usedInclusion of C 1999 Extensions [c99]

In C99 programs which are not C++ programs, some undefined behaviors canbe eliminated by using techniques already known in the current art. Thenext paragraphs will describe some exemplary such techniques.

The compiler can produce a fatal diagnostic message for the followingsituations which can be detected at compile-time: a function withexternal linkage is declared with an inline function specifier, but isnot also defined in the same translation unit; the CX_LIMITED_RANGE,FENV_AX2ESS, or FP_CONTRACT pragma is used in any context other thanoutside all external declarations or preceding all explicit declarationsand statements inside a compound statement; an argument to afloating-point classification or comparison macro is not of realfloating type; a complex argument is supplied for a generic parameter ofa type-generic macro that has no corresponding complex function; thetype of an argument to a type-generic macro is not compatible with thetype of the corresponding parameter of the selected function; part ofthe program tests floating-point status flags, sets floating-pointcontrol modes, or runs under non-default mode settings, but wastranslated with the state for the FENV_AX2ESS pragma off.

The implementation of library functions can in Debug mode strictlyvalidate argument values, and in non-Debug mode either strictly validateor adjust argument values to acceptable argument values.

The compiler can use Saturation semantics to produce well-definedresults for the following situation: the value of the result of aninteger arithmetic or conversion function cannot be represented.

The methods shown in this section can be used to eliminate the followingundefined behaviors:

SSM# C-Std# Description c99 c6.7.4 A function with external linkage isdeclared with an inline function specifier, but is not also defined inthe same translation unit c99 c7.3.4, c7.6.1, The CX_LIMITED_RANGE,FENV_AX2ESS, or FP_CONTRACT c7.12.2 pragma is used in any context otherthan outside all external declarations or preceding all explicitdeclarations and statements inside a compound statement c99 c7.12.3,c7.12.14 An argument to a floating-point classification or comparisonmacro is not of real floating type c99 c7.22 A complex argument issupplied for a generic parameter of a type- generic macro that has nocorresponding complex function c99 c7.22 The type of an argument to atype-generic macro is not compatible with the type of the correspondingparameter of the selected function c99 c7.6.1 Part of the program testsfloating-point status flags, sets floating- point control modes, or runsunder non-default mode settings, but was translated with the state forthe FENV AX2ESS pragma off c99 c7.6.2 The exception-mask argument forone of the functions that provide access to the floating-point statusflags has a nonzero value not obtained by bitwise OR of thefloating-point exception macros c99 c7.6.2.4 The fesetexceptflagfunction is used to set floating-point status flags that were notspecified in the call to the fegetexceptflag function that provided thevalue of the corresponding fexcept_t object c99 c7.6.4.3, c7.6.4.4 Theargument to fesetenv or feupdateenv is neither an object set by a callto fegetenv or feholdexcept, nor is it an environment macro c99c7.8.2.1, c7.8.2.2, The value of the result of an integer arithmetic orconversion c7.8.2.3, c7.8.2.4, function cannot be represented c7.20.6.1,c7.20.6.2, c7.20.1Conditionally-Defined Behaviors [cdef]

Many of the situations defined as undefined behavior could be moreprecisely delineated by permitting a reduced range of the alternatives(as has been described in various places in the current art). Thecompiler can implement a choice for each behavior: either produce afatal diagnostic message, or produce a specified implementation-definedbehavior, for each of the situations coded with “cdef” in column one ofthe following table.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description cdef c5.1.1.2 A nonempty source file does notend in a new-line character which is not immediately preceded by abackslash character or ends in a partial preprocessing token or commentcdef c6.6 A constant expression in an initializer is not, or does notevaluate to, one of the following: an arithmetic constant expression, .. . cdef c6.6 . . . a null pointer constant, an address constant, or anaddress constant for an object type plus or minus an integer constantexpression cdef c6.6 An arithmetic constant expression does not havearithmetic type; has operands that are not integer constants, floatingconstants, . . . cdef c6.6 . . . enumeration constants, characterconstants, or sizeof expressions; or contains casts (outside operands tosizeof operators) other than conversions of arithmetic types toarithmetic types cdef c6.6 An expression that is required to be aninteger constant expression does not have an integer type; has operandsthat are not integer constants, enumeration constants, characterconstants, sizeof expressions whose results are integer constants, or .. . cdef c6.6 . . . sizeof expressions whose results are integerconstants, or immediately- cast floating constants; or contains casts(outside operands to sizeof operators) other than conversions ofarithmetic types to integer types cdef c6.7.5.3 In a context requiringtwo function types to be compatible, they do not have compatible returntypes, or . . . cdef c6.7.5.3 . . . their parameters disagree in use ofthe ellipsis terminator or the number and type of parameter (afterdefault argument promotion, when there is no parameter type list or whenone type is specified by a function definition with an identifier list)cdef c5.1.1.2 A nonempty source file does not end in a new-linecharacter which is not immediately preceded by a backslash character . .. cdef c5.1.1.2 A nonempty source file . . . or ends in a partialpreprocessing token cdef c5.1.1.2 Token concatenation produces acharacter sequence matching the syntax of a universal character namecdef c5.1.2.2.1 A program in a hosted environment does not define afunction named main using one of the specified forms cdef c5.2.1 Acharacter not in the basic source character set is encountered in asource file, except in an identifier, a character constant, a stringliteral, a header name, a comment, or a preprocessing token that isnever converted to a token cdef c5.2.1.2 An identifier, comment, stringliteral, character constant, or header name contains an invalidmultibyte character or does not begin and end in the initial shift statecdef c6.10.1 The token defined is generated during the expansion of a#if or #elif preprocessing directive, or the use of the defined unaryoperator does not match one of the two specified forms prior to macroreplacement cdef c6.10.2 The #include preprocessing directive thatresults after expansion does not match one of the two header name formscdef c6.10.2 The character sequence in an #include preprocessingdirective does not start with a letter cdef c6.10.3 There are sequencesof preprocessing tokens within the list of macro arguments that wouldotherwise act as preprocessing directives cdef c6.10.3.2 The result ofthe preprocessing operator # is not a valid character string literalcdef c6.10.3.3 The result of the preprocessing operator ## is not avalid preprocessing token cdef c6.10.4 The #line preprocessing directivethat results after expansion does not match one of the two well-definedforms, or its digit sequence specifies zero or a number greater than2147483647 cdef c6.10.6 A #pragma STDC preprocessing directive does notmatch one of the well-defined forms cdef c6.10.8 The name of apredefined macro, or the identifier defined, is the subject of a #defineor #undef preprocessing directive cdef c6.2.2 The same identifier hasboth internal and external linkage in the same translation unit cdefc6.2.6.2 The arguments to certain operators are such that could producea negative zero result, but the implementation does not support negativezeros cdef c6.3.2.1 A non-array value with an incomplete type is used ina context that requires the value of the designated object cdef c6.3.2.1An lvalue having array type is converted to a pointer to the initialelement of the array, and the array object has register storage classcdef c6.3.2.2 An attempt is made to use the value of a void expression,or an implicit or explicit conversion (except to void) is applied to avoid expression cdef c6.3.2.3 Conversion between two pointer typesproduces a result that is incorrectly aligned cdef c6.4 An unmatched' orcharacter is encountered on a logical source line during tokenizationcdef c6.4.1 A reserved keyword token is used in translation phase 7 or 8for some purpose other than as a keyword cdef c6.4.2.1 A universalcharacter name in an identifier does not designate a character whoseencoding falls into one of the specified ranges cdef c6.4.2.1 Theinitial character of an identifier is a universal character namedesignating a digit cdef c6.4.2.1 Two identifiers differ only innonsignificant characters cdef c6.4.2.2 The identifier func isexplicitly declared cdef c6.4.7 The characters', \, , , c, c, or, c*occur in the sequence between the < and > delimiters, or thecharacters', \, , c, c, or, c* occur in the sequence between thedelimiters, in a header name preprocessing token cdef c6.5.4 A pointeris converted to other than an integer or pointer type cdef c6.6 Thevalue of an object is accessed by an array-subscript [ ], member-access. or ->, address &, or indirection * operator or a pointer cast increating an address constant cdef c6.7 An identifier for an object isdeclared with no linkage and the type of the object is incomplete afterits declarator, or after its init-declarator if it has an initializercdef c6.7.1 A function is declared at block scope with an explicitstorage-class specifier other than extern cdef c6.7.2.1 A structure orunion is defined as containing no named members cdef c6.7.2.3 When thecomplete type is needed, an incomplete structure or union type is notcompleted in the same scope by another declaration of the tag thatdefines the content cdef c6.7.3 The specification of a function typeincludes any type qualifiers cdef c6.7.3 Two qualified types that arerequired to be compatible do not have the identically qualified versionof a compatible type cdef c6.7.5.1 Two pointer types that are requiredto be compatible are not identically qualified, or are not pointers tocompatible types cdef c6.7.5.2 In a context requiring two array types tobe compatible, they do not have compatible element types, or their sizespecifiers evaluate to unequal values cdef c6.7.5.2 The size expressionin an array declaration is not a constant expression and evaluates atprogram execution time to a nonpositive value cdef c6.7.5.3 Astorage-class specifier or type qualifier modifies the keyword void as afunction parameter type list cdef c6.7.8 The initializer for a scalar isneither a single expression nor a single expression enclosed in bracescdef c6.7.8 The initializer for a structure or union object that hasautomatic storage duration is neither an initializer list nor a singleexpression that has compatible structure or union type cdef c6.7.8 Theinitializer for an aggregate or union, other than an array initializedby a string literal, is not a brace-enclosed list of initializers forits elements or members cdef c6.9.1 A function definition includes anidentifier list, but the types of the parameters are not declared in afollowing declaration list cdef c6.9.1 A function that accepts avariable number of arguments is defined without a parameter type listthat ends with the ellipsis notation cdef c6.9.1 An adjusted parametertype in a function definition is not an object type cdef c6.9.2 Anidentifier for an object with internal linkage and an incomplete type isdeclared with a tentative definition cdef c7.1.2 A header is includedwithin an external declaration or definition cdef c7.2 The argument tothe assert macro does not have a scalar type cdef c7_17 The memberdesignator parameter of an offsetof macro is an invalid right operand ofthe . operator for the type parameter, or designates a bit-field cdefc7_18.4 The argument in an instance of one of the integer-constantmacros is not a decimal, octal, or hexadecimal constant, or it has avalue that exceeds the limits for the corresponding typeDynamic Monitoring of Allocated Storage [dyna]

The methods described below will in some cases require a fataldiagnostic for situations in which the compiler and linker are giveninsufficient information to determine that fetch or store operations donot introduce undefined behavior. A recent article has published amethod which can alternatively be applied to these most-difficult cases:“A Practical Dynamic Buffer Overflow Detector”, by O. Ruwase and M. S.Lam, (http://suif.stanford.edu/papers/tunji04.pdf). In this alternative,unverifiable fetch-or-store operations can be checked by the citedmethods, requiring that all potential fetched-or-stored objects beentered into the cited tables.

It would be desirable to eliminate further undefined behaviors in theexecution of programs in the “intersection” of C and C++; that is, in Cprograms which use only the features described in the C++ standard, andof C++ programs which use only the features described in the C standard.

Furthermore, it would be desirable to eliminate undefined behaviors inthe execution of programs in “full C++”, i.e., of C++ programs which usefeatures which are not described in the C standard.

Additionally, it would be desirable to eliminate further undefinedbehaviors in the execution of programs in “full C99”, i.e., of C99programs which use features which are not described in the C++ standardor in the 1990 C standard.

It would furthermore be desirable to automate (e.g., through compilerdesign) techniques to provide safe secure development of software,including but not limited to techniques for addressing undefinedbehavior in the full C and C++ programming languages.

Advantageous features provided by exemplary illustrative non-limitingimplementations of the technology herein include:

-   -   A Safe Secure Compiler (“SSC”) which produces Safe Secure Object        Files or fatal diagnostic messages.    -   A Safe Secure Inputs Check-List (“SSICL”) which records checksum        information for the inputs to the execution of a Safe Secure        Compiler.    -   A Safe Secure Bounds Data File (“SSBDF”) which records        Requirements and Guarantees for the defined and undefined        symbols in one or more corresponding object files, as well as        checksum information.    -   A Safe Secure Linker (“SSL”) which combines object files and the        corresponding Safe Secure Bounds Data Files, producing either        fatal link-time diagnostics or a Safe Secure Executable Program.    -   A Safe Secure Semantic Analyzer (“SSSA”) which uses the parse        tree to determine Requirements and Guarantees.    -   A Safe Secure Diagnostic Generator (“SSDG”) which generates        fatal diagnostic messages in situations where undefined behavior        would result and generates various warning messages to call the        programmer's attention to various other situations.    -   A Safe Secure Code Generator (“SSCG”) which generates object        code which is free from the designated sets of undefined        behaviors (including “buffer overflow” and “null pointer        indirection”).    -   A Safe Secure Pointer Attribute Hierarchy (“SSPAH”) which        controls the inference of attributes based upon other        attributes.    -   A Safe Secure Pointer Attribute Predicate Table (“SSPAPT”) which        controls the determination of attributes resulting from        predicate expressions.    -   A Safe Secure Bounds Data Table (“SSBDT”) which tabulates the        Guarantees and Requirements for expressions, sub-expressions,        declarations, identifiers, and function prototypes.    -   A Safe Secure Interface Inference Table (“SSIIT”) which controls        the inference of Requirements on the interface of each        externally-callable function.    -   A Safe Secure Bounds Data Symbol Table (“SSBDST”) which        tabulates the Requirements and Guarantees for defined and        undefined symbols during the Safe Secure Linking process.    -   A Safe Secure Link-Time Analyzer (“SSLTA”) which matches        Requirements to Guarantees for function-call, external array,        and external pointer linkage contexts.    -   A Safe Secure Link Diagnostic Generator (“SSLDG”) which        generates a fatal diagnostic at link-time if any Requirement is        unsatisfied; this prevents the production of any executable        program.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages will be better and morecompletely understood by referring to the following detailed descriptionof exemplary non-limiting illustrative embodiments in conjunction withthe drawings of which:

FIG. 1 shows an example safe secure software development system;

FIG. 2 shows a flow diagram of an exemplary illustrative non-limitingimplementation of a program translation system;

FIG. 3 shows a block diagram of an exemplary illustrative non-limitingcompiler implementation;

FIG. 4 shows exemplary illustrative annotation of pointer-null-state toa non-limiting illustrative flow-chart;

FIG. 5 shows a different exemplary illustrative representation of thesame flow-chart;

FIG. 6 shows a further exemplary illustrative flow-chart, including some“can't-happen” outcomes;

FIG. 7 shows an exemplary illustrative non-limiting Safe Secure PointerAttribute Hierarchy (SSPAH 41);

FIG. 8 shows an exemplary illustrative non-limiting Safe Secure PointerAttribute Predicate Table (SSPAPT 51);

FIG. 9 shows exemplary illustrative non-limiting components of a SafeSecure Semantic Analyzer (SSSA 35);

FIG. 10 shows an exemplary illustrative non-limiting Safe SecureInterface Inference Table (SSIIT Y111); and

FIG. 11 shows exemplary illustrative non-limiting components of the SafeSecure Linker (SSL 28).

DETAILED DESCRIPTION

FIG. 1 shows an example illustrative non-limiting automated safe securecomputer software development system 100. For example, an exemplarynon-limiting system 100 may comprise a central processing unit (CPU) 11coupled to a mass storage device 2 such as a magnetic or other disk. TheCPU 11 may execute program instructions including for example a safesecure translator 13 the executable code for which is stored on the massstorage device and executed by CPU 11. When executed by CPU 11, thetranslator 13, in simplified terms, takes a source code input 14 andconverts it to an executable output 15 that can be executed by the sameor different computer. The computer system 100 may further includeinput/output devices 16 such as for example keyboards, pointing devices,display devices and the like so that human software developers caninteract with the computer. In one exemplary arrangement, the techniquesdescribed herein can be used to enhance a conventional compiler for theC and C++ programming language (as will be described below) to eliminateundefined behavior.

Referring to FIG. 2, consider the following source program serving as anon-limiting illustrative example of Source Program 21 providing inputto Safe Secure Compiler 23:

int main( ) { return 0; }

Exemplary components of Safe Secure Translator 13 are shown in FIG. 3.In compiling this example, Lexical Analyzer 31, Preprocessor 32, andParser 33 perform as commonly understood in the art. Then, SemanticAnalyzer 34 verifies that the integer 0 is an acceptable value to returnfrom the function “main” which is defined to return “int”. After that,the Code Generator 38 will produce an Object File 25, the ultimateoutput from Safe Secure Compiler 23. Finally, the Safe Secure Linker 28will combine the Object File 25 with various system-dependent librarycode, producing Executable Program 29.

States of Objects [stat]

The standards for C and C++ make use of modifiers upon types, known as“qualifiers” in C and “cv-qualifiers” in C++. Once declared, anidentifier that designates an object (region of memory) retains its typeand cv-qualifiers throughout its scope. A related concept, butdistinctly different, is the state of an object.

One well-known state in modern programming languages is the “definitelyassigned” state. Definite-assignment analysis is a central feature ofthe Java and C# programming languages. The present exemplaryillustrative implementation of a Safe Secure method does not use thedefinitely-assigned state in quite the same way, but does make extensiveuse of state analysis. One example of a state used in the Safe Securemethod is the pointer-null-state, which has three alternative statevalues. (The pointer-null-state in this example is one dimension of amore complicated pointer-range-state, shown later.)

-   -   a. Nul—pointer is null.    -   b. Nnul—pointer is non-null.    -   c. Qnul—pointer might, or might not, be null; i.e.        “questionably-null”.

Analysis of program state proceeds using flow analysis. Consider thefollowing source program serving as another non-limiting illustrativeexample of Source Program 21 providing input to Safe Secure Compiler 23:

int main( ) { int *p = (int*)0; return *p; }

As described previously, Lexical Analyzer 31, Preprocessor 32, andParser 33 perform as commonly understood in the art. Semantic Analyzer34 determines that pointer p is initialized on its declaration anddetermines that the initial value is the null pointer value. WithinSemantic Analyzer 34, control flow analysis determines that there is notransfer of control in or out of the control-flow arc from the point ofinitialization to the point of usage (which attempts to fetch a valuefrom the target of pointer p) and data-flow analysis determines thatthere are no alterations of the value of pointer p within that arc.Control-flow analysis and data-flow analysis are commonly used tosupport optimization, but they also provide input data for theDiagnostic Generator 36. In the present example, the Semantic Analyzer34 will commonly provide to the Diagnostic Generator 36 data indicatingthat upon all possible arcs the program would encounter the indirectingof a null pointer, and the Diagnostic Generator 36 will commonly producea fatal diagnostic message and will commonly prevent the Code Generator38 from producing any object code. (Each use of the term “fataldiagnostic” implies without exception that object code is never producedfor any program which causes a fatal diagnostic.)

Consider this portion of another Source Program 21:

if (p!=0) ++n;

FIG. 4 shows the flowchart which corresponds to the control flow in thisexample. In this conventional flowchart presentation, the two arcsre-join into the same flow-of-control (program counter) state, but thepointer-null-state of p is different after the branch. An alternativepresentation provides numbers (or labels) to each flow-of-control state,but records the continuation of each arc as a distinctly differentstate, as shown in FIG. 5. The difference is made clearer by addinganother instruction to the example:

if (p!=0) ++n; if (p==0) ++m;

The resulting flowchart is shown in FIG. 6. The Safe Secure SemanticAnalyzer (“SSSA”) 35 verifies that the pointer-null-state of pointer ppre-determines the outcomes of the second “if” statement, so there areonly two actual flow-of-control paths in the flowchart of FIG. 6. In theSSSA 35 the flow chart of each function is factored into separatecontinuations of each arc at every place in the function, except thatall arcs re-join at the return from the function (and the epilog impliedby that return).

The concept of “state” applies to objects during run-time. Herein, theterm “attribute” is used for the compile-time designation of a run-timestate of an identifier or expression.

As will be explained below, the compile-time attributes as used in theSSSA 35 are sometimes capable of modeling every detail of the run-timestate analysis; in these cases the compile-time attributes are all thatis needed in the analysis. In other cases, the compile-time attributesare capable of modeling many, but not all, details of the run-time stateanalysis; in these cases, the compile-time attributes permitcompile-time diagnosis of many but not all errors. Therefore, thesecases will require some bits in the run-time storage to record run-timestate information.

With this background, we can describe the system of pointer-range statesand attributes that is employed in the SSSA 35. We distinguish thefollowing attributes of pointers, noting that the attributes are notmutually exclusive:

Attribute Description Unk Unknown Nul Null Ni not-indirectable Nnulnon-null Qnul maybe-null = nul or nnul Qi maybe-indirectable =indirectable or nul Nth not too high Ntl not too low End one-too-far IIndirectable Lo At Lo limit Hi At Hi limit Nullterm At or before Hi,null-terminator is present Length Number of characters prior tonull-terminator T target is defined

Some attributes imply other attributes; see the Safe Secure PointerAttribute Hierarchy (“SSPAH”) 41 in FIG. 7 for details.

When the source program contains a test (i.e., predicate) to a pointer(or subscript) value, that pointer's attribute will be set, upon thetrue and false outcome arcs from that predicate; see the Safe SecurePointer Attribute Predicate Table (“SSPAPT”) 51 in FIG. 8 for details.

The Lo, Hi, End, Nth, and Ntl attributes can be applied either to apointer or to a subscript (if the subscript's array context is clear).

The spelling and/or capitalization of the names of the attributes,values, Requirements, and Guarantees are not essential, and can bechosen to meet any other requirements. For a non-limiting example, theattribute name “Nullterm” could be abbreviated as “Nullt”, and theattribute name “Indirectable” could be abbreviated as “Indir”, providedthat those names are unambiguous in the context in which they are used.

To determine the state transition for the Nullterm attribute, the SSSA35 first determines the outcome Indirectable (“I”) attribute; if theoutcome attribute is I then it is also Nullterm; if it is not I then itis not Nullterm either. For example if a pointer p is Nullterm, andcomparison <=Hi is True, the result attribute is I and is also Nullterm.But if the comparison is False, the result attribute is Ni and notNullterm.

The present method does not require that the null pointer compares lowto all other pointer values. In an alternative method, this requirement(“unsigned pointer comparison”) is added to the pointer semantics;“nul>=Lo” becomes a “can't happen” condition that produces the “Ntl”attribute, and “nul>Hi” becomes a “can't happen” condition that producesthe “Ni” attribute.

The Safe Secure method relies heavily upon analysis of pointer-boundsstates, but there are some other significant states of storage.

In C and C++, a union can contain objects of different types atdifferent times. In the present Safe Secure method there are no traprepresentations; any sequence of bytes can be fetched without causingany exceptions, and those bytes determine a value within the range ofvalues for the type of the 1 value. Therefore, accessing a union objectthrough an 1 value of an “incorrect” type may produce an incorrect valuebut will not cause an exception or any undefined behavior. Assigning avalue to a union member determines the current effective type of theunion, which is an important aspect of the run-time system of states. Inthe Safe Secure method, assigning a pointer (address) value to a unionobject establishes the state of all union members which are pointers totypes with the same representation and alignment. Consider the followingexample:

union { char *p; unsigned char *q; int n; } u; char a[3] = “ab”; u.p =a; // u.p and u.q are in Indirectable (i) state, and equal to Lo of au.n = 0; // u.p and u.q are in Unknown (unk) state

In the terminology of the Safe Secure method, all the attributes shownso far appear as Guarantees, i.e. post-conditions, established byvarious predicates on arcs of control flow. In subsequent sections,attributes will be used in Requirements, i.e. pre-conditions,

Stream objects can in one exemplary implementation contain an “is-open”run-time state which is reflected in a compile-time attribute (callede.g. “is_open”). The representation of the is-open state can in oneexemplary implementation be non-zero.

After the standard C and C++ library function setvbuf is invoked, thecalling program should make no further use of the array provided to thebuf argument. In the Safe Secure Bounds Data File 26 which contains datafor the setvbuf function, a post-condition specifies that the bufargument is Not-Indirectable after invocation, using methods defined inthe next section.

In some cases, after consideration of all compile-time and link-timerestrictions, a Requirement can be guaranteed only by inserting extrarun-time code. The extra run-time code is usually of no concern in theDebug mode. However, in Non-Debug mode the overhead of any insertedrun-time code is of crucial importance.

The process of “code hoisting” is well understood in the prior art. Werely upon code hoisting to pull inserted run-time code out of the innerloops. However, some additional techniques of code hoisting aredescribed below.

In most algorithms involving a subscript or pointer variable, thevariable is monotonically incremented toward some limit which is lessthan or equal to the Hi or End value. In a few cases, the monotonicincrementing is interrupted by a bounded number of decrements, which thecompiler can determine to never go below the Lo value. Somewhat lesscommonly, the same two patterns are found in the downward (decrementing)direction: either monotonic decrementing, or decrementing interrupted bybounded incrementing.

In all the cases described in the preceding paragraph, even if thecompiler cannot determine (at compile-time) that the variable does notexceed the appropriate limit in its direction of travel, there is noneed to redundantly verify that it has not exceeded the opposite limit.In other words, at most one test is required in these cases, not two.

In some of these cases, the compiler can determine that the variablewill not exceed (above or below) the value of some other variable, e.g.the value of a loop limit, but cannot determine that the loop limit doesnot exceed the appropriate bounding value (the Bound, Tsize, Lo, Hi, orEnd value). In such cases, it suffices for the compiler to generate codewhich verifies that the bounding value (e.g. loop limit) does not exceedthe appropriate bounding value, rather than redundantly checking thevalue of the subscript or pointer variable itself at each access.

The remainder of this section will focus upon code generation for thenon-Debug mode(s) which emphasize a “keep on running” (“KOR”) logic,such as _Modwrap, _Sat, and _Zerobound logic. The generated assemblercode can use assembler conditional instructions to avoid introducingbranches. The alternatives of _Modwrap, _Sat, and _Zerobound can beevaluated by the Safe-Secure Code Generator (“SSCG”) 39 to determinewhich alternative produces optimal assembler code. (The name“_Saturation” can be used as equivalent to “_Sat”.)

For a non-limiting example, in _Sat logic where a subscript or pointer Nshould not exceed a Hi value, the generated assembler can use assemblerconditional instructions such as Load N, Cmp Hi, Load Hi if Greater.

For another non-limiting example, if the processor supports only a _Satlogic that saturates at a UINT_MAX value (call it P), then the generatedassembler can saturate at an arbitrary Bound using an “Add-Sat”instruction (add with saturation at P) such as Load N, Add-Sat(P-Bound), Subtract (P-Bound).

For another non-limiting example, if Bound is a power of two, then_Modwrap is provided by bitwise-and. In a further version of thisexample, one option to be evaluated in code optimization is to allocateextra elements in the (static, stack, or allocated) array to make itsactual Bound be the next higher power of two. Note that the resultingNon-Debug code will propagate Guarantees using a larger (power-of-two)Bound (and Hi, and End) than the exact values that are used in thecorresponding Debug version of the same program.

For another non-limiting example, if the (possibly-adjusted) Bound isexactly 255 or 2,767, then the generated assembler code can maintain asubscript value N as a one-byte or two-byte value within a larger value,using one-byte or two-byte instructions, which will act as if everystore of N were bitwise-anded with 0xFF or 0xFFFF before each store.

For another non-limiting example, _Zerobound logic can be implementedusing conditional assembler instructions, such as Load P, Cmp Bound(producing a zero or non-zero value), Load *P if nonzero (leaving thezero result of comparison as the result value of the _Zerobound logic).

Previous examples have focused upon the ways the Bounds information candetermine whether a pointer or subscript is Indirectable orNot-Indirectable. However, Alignment requirements play a similar role.For example, if a pointer-to-int is cast to pointer-to-char, the char*result is always Indirectable. If flow analysis determines that nochanges have been made to the value, and the pointer-to-char is castback to pointer-to-int, then the int* result is Indirectable. However,if the value has been changed (incremented, decremented, added,subtracted, etc.), then the int* result is Not-Indirectable. If theresult is used in a context imposing a Requirement of Indirectable, thenthe Safe Secure Code Generator can insert run-time assistance: in Debugmode, insert a test to determine whether the value is properly aligned.In non-Debug mode, insert a forcible alignment. (For the basic typeswhich occupy power-of-two sizes, the forcible alignment can simply be abitwise-and with a mask containing low-order zeroes.)

The SSC 23 can require that any type instantiated in the Cod complex andvalarray templates shall have no operations that throw exceptions.

The SSC 23 can require that the argument to the constructor of anauto_ptr is a new-expression, guaranteeing that there are no aliasedcopies of the argument object.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description stat c6.2.4, The value of an object withautomatic storage duration is used while it is c6.7.8, c6.8indeterminate stat c7.19.3 The value of a pointer to a FILE object isused after the associated file is closed stat c6.5.3.2 The operand ofthe unary * operator has an invalid value stat c7.19.5.3 An outputoperation on an update stream is followed by an input operation withoutan intervening call to the fflush function or a file positioningfunction, . . . stat c7.19.5.3 . . . or an input operation on an updatestream is followed by an output operation with an intervening call to afile positioning function stat c7.19.5.6 An attempt is made to use thecontents of the array that was supplied in a call to the setvbuffunction stat c7.19.7.11 The file position indicator for a binary streamis used after a call to the ungetc function where its value was zerobefore the call stat c7.19.9.2 The fseek function is called for a textstream with a nonzero offset and either the offset was not returned by aprevious successful call to the ftell function on a stream associatedwith the same file or whence is not SEEK_SET stat c7.19.9.3 The fsetposfunction is called to set a position that was not returned by a previoussuccessful call to the fgetpos function on a stream associated with thesame file SSM# C++-Std# Description stat 20.4.5 para 3 More than oneauto_ptr owns the same object stat 26.1 para 2 Any operation on T throwsan exceptionSafe Pointers [buf]

In the present method, all pointers are implemented as“compile-time-safe pointers”, subject to a maximal verification atcompile time.

The target-size, or Tsize, is defined as the number of bytes in theobject or array designated by the pointer. The Bound is defined as theTsize divided by the size of the type T to which the pointer ispointing. The Tsize-adjusted is the Tsize minus the size of the type T,i.e. the number of bytes in the array between the address of the firstobject of type T and the last object of type T. If there is only oneelement in the array, the Tsize-adjusted is zero.

The SSSA 35 maintains this bounds information for every pointer used tofetch-or-store; therefore, the analysis presented in this Safe Securemethod will incorporate the syntax and semantics of the restrict keyword(from C99). Whenever this keyword appears, it reflects in syntax arestriction that otherwise must be stated in (non-formalized) semantics,i.e. a restriction that the target object designated by therestrict-qualified pointer does not overlap any other object that isaccessible through external pointers or other argument pointers. Thisrestriction can in one exemplary implementation be verified atcompile-time to the extent that the bounds information is available. Theremaining checks can in one exemplary implementation be verified atrun-time by examination of the bounds data of the fore-mentioned set ofpointers. Note that the restrict keyword is not part of the (1998 or2002) C++ standard, but the no-overlap restriction is part of the(non-formalized) semantics of the C library contained in that C++standard, and therefore is part of the requirements for the eliminationof undefined behavior in C++ as well as C.

Components of the SSSA 35 are as shown in FIG. 9.

A pointer value that designates an object in an array has a compile-timerelationship with the bounding addresses of the array. When a pointervalue is assigned to a pointer object, the target pointer objectreceives all the attributes pertaining to the original pointer. Allpointer arithmetic (ptr+n, ptr−n, ptr−ptr, ptr[n]) checks the result (atcompile-time, link-time, or run-time) against the Lo-Hi bounds; the End(“one-too-far”) value is permissible as a result from pointerarithmetic. Fetching or storing via indirection operators (explicitlyvia “star” or implicitly in the 1 value use of subscript) causes theSSSA 35 to check the pointer or subscript against the Lo-Hi bounds; the“one-too-far” value is not permissible for fetching or storing. If atrun-time, any bounds are exceeded, in Debug mode ss_unwind is invoked(see Ss_unwind [longj]); in non-Debug mode the semantics of _Sat,_Modwrap or _Zerobound (defined later in this section) may be producedby the SSCG 39, based upon considerations of best performance. In thealternative, any algorithm of alternating between semantics isallowable. The underlying intent of this alternative is that programmerswill not be given an expectation that any specific semantics ispredictable or deterministic.

A compile-time-safe pointer uses the same (one-word) representation asthe ordinary C or C++ implementation. In all contexts that requirebounds information, that information is made known to the SSSA 35through a variety of mechanisms. In compile-time-safe code, the SSSA 35ensures that each non-scalar pointer must have, within the same region(global static, block static, block local, parameters, or heap) boundsinformation (or bounds information stored in the global static region),stored in locations made known to the Safe Secure Compiler 23,sufficient to verify the safety of any fetches or stores expressed inthe program.

Here is an itemization of the contexts that require or use boundsinformation for a pointer: arithmetic (p+n, p−n, p−p), subscripting(p[n] and n[p]), pointer argument passing, returning a pointer, takingthe address-of, pointer copying and assignment. For each pointervariable or expression appearing in a context which requires boundsinformation, that bounds information is inferred by the SSSA 35, usingone of several alternative methods.

The SSSA 35 stores Guarantees and Requirements for pointer bounds in theSafe Secure Bounds-Data Table (“SSBDT”) 61. A subset of this informationis also stored in the Safe Secure Bounds-Data File (“SSBDF”) 26, namelyall bounds data entries which provide information about the Requirementsand Guarantees of references to, and definitions of, external arrays,external pointers, and the parameters and return type ofexternally-callable functions, i.e. function prototype entries. At orbefore termination of execution of the SSSA 35, all such entries in theSSBDT 61 are written to the SSBDF 26 contained in a persistent storage(“file storage”).

The format and representation of the SSBDT 61 can be optimized to suitthe requirements of each SSSA 35. In the SSBDT 61, the Guarantees andRequirements are attached as needed to expressions, sub-expressions,declarations, identifiers, and function prototypes, using whateverindexing or coordinates as are needed to identify the relevant locationin the internal representation of the Parser 33. For purposes ofpresentation in the present Safe Secure method, all entries in the SSBDT61 will be represented in the narrative text or in the style of macroinvocations inserted into the Source Program 107. In the present method,this representation does not presuppose that any such invocations ofactual macros are present in the actual Source Program 107. The SafeSecure method requires that one or more of the following are provided:

-   -   1. The Parser 33 recognizes some notation identical to or        equivalent to the macro notation shown herein; or,    -   2. The SSSA 35 provides a method whereby the human programmer        can add annotations to the SSBDT 61 and SSBDF 26. If the        Compiler 23 is a component in an Interactive Design Environment        (IDE), then the mechanism for adding annotations to the SSBDT 61        and SSBDF 26 can be integrated into the IDE.

The concepts of pre-condition and post-condition are well-known. Notethat “Requirement” as used herein is synonymous with “pre-condition” andthat “Guarantee” is synonymous with “post-condition”, with the followingcontextual difference: in some technology communities the terms“pre-condition” and “post-condition” are primarily used for annotationsmade by the human programmer. The choice herein of different terminologyis intended to avoid this connotation; the huge number of Requirementsand Guarantees required by the Safe Secure methods would be anunreasonable burden if performed only by human annotation.

The entries in the SSBDT 61 are represented as follows:

char *p BOUND_IS(n) n provides the Bound of p. char *p LENGTH_IS(n) nprovides the Length of p char *p TSIZE_IS(n) n provides the Tsize ofchar *p TSIZEA_IS(n) n provides the Tsize-adjusted of p char *pINDIRECTABLE p is Indirectable char *p NOT_INDIRECTABLE p is NotIndirectable char a[ ] LO_IS(p) p provides the Lo of a char HI_IS(p) a[] p provides the Hi of a char LO_IS(p) HI_IS(q) a[ ] p provides the Loof a and q provides the Hi of a

For convenience and flexibility, alternative annotations are provided,which can be attached to the declaration of the integer or pointer whichis providing the bounds information:

int n IS_BOUND_OF(p) n provides the Bound of p int n IS_LENGTH_OF(p) nprovides the Length of p int n IS_TSIZE_OF((p,q)) n provides the Tsizeof p and of q int n IS_TSIZEA_OF((p,q,r)) n provides the Tsize-adjustedof p, of q, and of q char *p IS_HI_OF (a) p provides the Hi of a char *pIS_LO_OF(a) p provides the Lo of a char *p IS_END_OF(a) p provides theEnd of a

As indicated by the last examples, all the IS_*_OF annotations accept avariable number of names, enclosed within a second level of parentheses.

If the Lo bound is not explicitly specified, then the initial value ofeach pointer in each scope is initially the Lo bound. The initial Lobound plus the initial Bound (or Length or Tsize) value determines theHi bound.

The default for a pointer without any bounds annotation isNot-Indirectable.

The SSSA 35 can infer from the source code of a function that aparameter is being used as the Hi, or Bound, or Length, or Tsize, ofanother parameter. The itemized set of rules for the inference isdetailed in FIG. 10.

There are several special cases for the bounds annotations in the SSBDT61:

int n IS_BOUND_OF(return) n provides the Bound of the function'sreturned pointer int n IS_LENGTH_OF(return) n provides the Length of thefunction's returned pointer int IS_TSIZE_OF(return) n provides the Tsizeof the function's returned pointer char *p IS_HI_OF(return) p providesthe Hi of the function's returned pointer char * QI(return) f( ) {function f returns a Maybe-Indirectable return value

Note that any attributes provided for the function's returned value arealways Guarantees and never Requirements, because the returned valuecomes into existence only upon function return. Attributes provided forthe function's parameters are both Requirements and Guarantees (unlessspecifically indicated otherwise), since the attribute is presumed tohold before and after execution of the function.

The SSBDT 61 also uses a special notation for NULLTERM, for char arrayswhich are guaranteed to be null-terminated:

int main(int argc, NULLTERM char* argv[ ] BOUND_IS(argc));

In the SSBDT 61, void* generic pointers are annotated just the same aschar* pointers.

When one parameter (such as n in this example) provides bounds data fora pointer (such as s1 in this example), that pointer is understood to beIndirectable. However, if one parameter provides bounds data but apointer is explicitly Maybe-Indirectable, then either the pointer isnull or it is indirectable and has bounds data.

If both Tsize and Bound are specified for the same object, then theTsize is the Tsize of one element, and the Bound is the number ofelements. For a non-limiting example, the standard library functioncalloc is represented in the SSBDT 61 as follows:

void * QI(return) calloc(  size_t a IS_BOUND_OF(return), size_t bIS_TSIZE_OF(return)  );

If both Tsize (or other bounds data) and Nullterm are specified for thesame pointer, then the Tsize is understood as the largest object thatwill be accessed through this pointer. For example, the standard libraryfunction strncpy is represented in the SSBDT 61 as follows:

char * strncpy(  char *s1, const char *s2 NULLTERM, size_t nIS_TSIZE_OF((s1,s2))  );

In the notation described so far, the attributes for “indirectable” and“null-terminated” represent Requirements-and-Guarantees for argumentsand Guarantees for returned value. These attributes can also be used forGuarantees (post-conditions) upon an argument when there is nocorresponding Requirement (pre-condition) upon entry to the function. Anadditional marker (“POST”) is used to indicate post-conditions(Guarantees) in the notation of the SSBDT 61:

int swprintf(wchar_t * restrict s POST(NULLTERM) LENGTH_IS(return),   size_t n IS_BOUND_OF(s),    const wchar_t * restrict format NULLTERM,...);

This notation indicates that there is no Requirement fornull-termination of s upon entry to the swprintf function, but there isa Guarantee of null-termination upon return from the function.

When a pointer or subscript which has a bounds attribute is assigned toanother pointer or integer variable, both the source and the targetacquire that specific bounds attribute. When one of those variables ismodified, the other variable retains the bounds attribute. For anon-limiting example, if a pointer equals the Lo bound, and then thatpointer is incremented, then any other Lo for that pointer retains itsLo attribute. Here is a non-limiting example:

void f(int *p) {  int *q = p; // p and q are the LO of p and the LO of q ++p; // now only q is the LO of p; it is also the LO of q

At any particular point in the control flow of the Source Program 107,attribute information might be redundantly attached to several differentobjects. If one of these objects is subsequently modified, anotherobject may retain the attribute as before. Here is a non-limitingexample:

void f(int n, int *p BOUND_IS(n)) {  int *q = p + n; // at this point, qis the END of p  −n; // because q holds the END value, n is no longerBOUND_OF(p)

The SSSA 34 embodies a rule that can be summarized informally as “half aloaf is better than none”: if there is only one copy of the LO, HI, END,BOUND, TSIZE, TSIZEA, or LENGTH, and if that copy is incremented ordecremented, then that copy retains the appropriate attribute. Here isan illustrative non-limiting example:

void f(char *p) { int a[n] = {0}; // at this point, n is the BOUND of aint *p = a;  // now, p is the LO of a and the LO of p, and n is theBOUND of p −n;  // because we haven't saved the END value, n is our onlyBOUND_OF(p)

Here is a similar non-limiting example:

int n = N; int a[N] = {0}; // at this point, n is the BOUND of p int *p= a; // now, p is the LO of a and the LO of p int *q = p + n; // at thispoint, q is the END of p −n; // because we saved the END value, n is nolonger BOUND_OF(p)

In the SSBDT 61 there is no need to re-state the type information thatwas present in the function prototypes; the table needs only to containthe bounds-data annotations. Some of the subsequent non-limitingexamples of SSBDT 61 notation will omit extraneous type information topermit more concise presentation. However, complicated declarators suchas pointer-to-pointer will still require some way to show which level ofpointer or array the annotation pertains to; these methods areindifferent to the specific scheme of notation. The present methodcovers the functional behavior of the use of the bounds data withoutlimitation to one specific notation.

In some cases, separate bounds-data entries are required for theseparate annotation of SUCCEED and FAIL cases (and see Functioninvocation patterns [invoc]). For a non-limiting example, consider thetwo separate annotations which the SSSA 35 would make in the SSBDT 61after analyzing the standard C and C++ library function fgets:

SUCCEED fgets(s POST(NULLT), n IS_TSIZE_OF(s), stream INDIR) FAIL   fgets(s, n IS_TSIZE_OF(s), stream INDIR)

This notation means that when fgets returns successfully, the stringpointed to by s is null-terminated; when fgets returns unsuccessfully,there is no Guarantee about null-termination. In either case, n is theTsize of s (a Requirement upon entry to fgets, and a Guarantee uponreturn from fgets), and stream is Indirectable (a Requirement upon entryto fgets, and a Guarantee upon return from fgets).

When the Requirements and Guarantees within one function are differentin different blocks within the function, and when one set of such blocksis controlled by an if-else test upon a parameter value, that functionis analyzed as two separate functions which depend upon an attribute ofan argument. For a non-limiting example, consider the two separateannotations which the SSSA 35 would make in the SSBDT 61 after analyzingthe standard C and C++ library function mbtowc:

mbtowc(pwc, s IS_NULL, n) mbtowc(pwc INDIR, s, n IS_TSIZE_OF(s) )

For further non-limiting examples of the annotation in the SSBDT 61 (andthe various special cases mentioned above), consider the followingbounds-data entries for various functions from the C and C++ standardlibrary.

setbuf(stream INDIR, buf INDIR) setvbuf(stream INDIR, buf IS_NULL, mode,size) setvbuf(stream INDIR, buf POST NOT_INDIR, mode, sizeIS_TSIZE_OF(buf) ) vfprintf(stream INDIR, fmt NULLT, arg) fgetpos(streamINDIR, pos INDIR) fclose(stream INDIR) fsetpos(stream INDIR, pos INDIR)fseek(stream INDIR, offset, whence) wcstombs(s POST NULLT, pwcs NULLT, nIS_BOUND_OF(s) ) SUCCEED fgets(s POST(NULLT), n IS_TSIZE_OF(s), streamINDIR) FAIL fgets(s, n IS_TSIZE_OF(s), stream INDIR) vsnprintf(s POSTNULLT, n IS_BOUND_OF(s), fmt NULLT, arg) wctomb(s BOUND_IS(MB_CUR_MAX),wc) fopen(filename NULLT, mode NULLT) freopen(filename NULLT, modeNULLT, stream INDIR) vprintf(fmt NULLT, arg) strtod(nptr NULLT, endptrIS_NULL) strtod(nptr NULLT, char NULLT ** endptr INDIR) strtol(nptrNULLT, endptr IS_NULL, base) strtod(nptr NULLT, char NULLT ** endptrINDIR, base) fputs(s NULLT, stream INDIR) remove(filename NULLT)rename(old NULLT, new NULLT) strchr(s NULLT, c) mblen(s IS_NULL, n)mblen(s NULLT, n IS_BOUND_OF(s) ) strncmp(s1 NULLT, s2 NULLT, nIS_BOUND_OF((s1,s2)) ) fwrite(ptr, size IS_TSIZE_OF(ptr), nmembIS_BOUND_OF(s), stream INDIR) bsearch(key, base, n IS_BOUND_OF(base),size IS_TSIZE_OF((key,base)), cmp INDIR) memchr(s NULLT, c, nIS_TSIZE_OF(s) ) memcmp(s1, s2, n IS_TSIZE_OF((s1,s2)) ) fputc(int c,stream INDIR) fread(ptr, size IS_TSIZE_OF(ptr), nmemb IS_BOUND_OF(ptr),stream INDIR) memcpy(s1, s2, n IS_TSIZE_OF((s1,s2)) ) qsort(base, nmembIS_BOUND_OF(base), size IS_TSIZE_OF(base), cmp INDIR) memset(s, c, nIS_TSIZE_OF(s)) ) memmove(s1, s2, n IS_TSIZE_OF((s1,s2,return)) )mbtowc(pwc, s IS_NULL, n) mbtowc(pwc INDIR, s, n IS_TSIZE_OF(s) )mbstowcs(pwcs, s, n IS_BOUND_OF(pwcs) )

As has been shown, the bounds information for a pointer is madeavailable to the Safe Secure Compiler 23 through a variety of mechanismsdepending upon the context: explicit attribute macros in a callingsequence (or equivalent programmer notations through IDE or othermeans), attributes inferred from usage in the called function, a visibleallocation expression such as malloc or new, information made known tothe linker by the SSBDF 26, or from direct visibility of an arraydeclaration. If the programmer has provided explicit notations of boundsinformation, the Safe Secure Compiler 23 checks them against theinferred bounds; otherwise, the inferred bounds will be used during thecompilation. It is likely that professional programmers providinglibrary code for consumption by others will be urged to provide explicitnotations.

When the Safe Secure Compiler 23 can see the assignment ptr=malloc(n)(or other standardized allocation), the specific bounds macros (LO_IS,HI_IS, END_IS, BOUND_IS, TSIZE_IS, TSIZEA_IS) are allowed but notrequired, because the Safe Secure Compiler 23 can infer that variable nIS_TSIZE_OF(ptr). So long as the variable n is not subsequentlymodified, it provides bounds information for ptr. Even if the argumentto malloc has been modified, when the SSSA 35 determines that the ptr isunmodified from the original returned value, the SSCG 39 generates codeto implement all the bounds macros (LO_OF, HI_OF, END_OF, BOUND_OF,TSIZE_OF, TSIZEA-OF) by accessing the heap-allocation data of thepointer ptr. However, if the function passes ptr as an argument to anexternal function, the function must pass the bounds information throughan argument. The SSBDF 26 does not provide notation to distinguishdynamically-allocated pointer arguments from ordinary pointer arguments.

Analysis of pointer-range-state starts by identifying all fetch-or-storeexpressions that involve pointers or subscripts, and all objects andvariables (i.e. named objects) that are part of those expressions. Next,identify all expressions and statements that involve those objects andvariables. Then identify certain control-flow patterns which guaranteethe “counted-loop” (“counted-plus” and “counted-minus”) semantics.

The process can be illustrated with a small non-limiting example:

int m[2] = {1, 2}; int main( ) {  int i, j = 0;  for (i = 0; i < 2; ++i)  j += m[i];  return j; }

Since m is defined in this translation unit, its bounds are known to theSSSA 35; specifically, its Bound is 2, its Lo is the address of m[0],its Hi is the address of m[1], and its End is the address of m[2]. TheTsize of m is 2 times sizeof(int), and its Tsize-adjusted issizeof(int). There is only one fetch-or-store expression involvingpointers or subscripts; it is the expression m[i]. The variablesinvolved in this expression are m and i. As the Practitioner knows, thesemantics of C and C++ requires that the subscript expression m[i] mustbe within the range of Lo to Hi; we designate this as the Requirement ofthe expression. The expressions and statements that involve thosevariables are contained in the one for-loop. The for-loop matches one ofthe “counted-plus” patterns, therefore the subscripting is valid. In ourterminology, we refer to the for-loop as the Guarantee that satisfiesthe Requirement given above. Another way of stating this Requirement isthat “i is a Subscript-For the array m”. (For a compact notation, we canwrite “i SUB4(m)”. The same Requirement can be applied to pointers; “pSUB4(m)” means that p is bounded between the Lo and Hi of m.) A slightlydifferent Requirement is that “i is a Subscript-For (or End of) thearray m” which we could abbreviate “i SUB5(m)”, and similarly forpointers, where “p SUB5(m)” means that p is bounded between the Lo andEnd of m.

When recognizing the patterns for a counted-loop (counted-plus andcounted-minus), subscripting expressions can be converted into pointerexpressions and vice-versa. Some patterns may be expressed more easilywith subscripts and others with pointers. The previous example can beconverted into this equivalent example:

int m[2] = {1, 2}; int main( ) {  int *pi;  int j = 0;  for (pi = &m[0];pi < &m[2]; ++pi)   j += *pi;  return j; }

A scalar pointer is one which, in its scope and lifetime, is neverincremented/decremented, never participates in address arithmetic, andis never subscripted (except using p[0]). It does not require boundsinformation.

The rules for a counted-loop (counted-plus and/or counted-minus) are thesame whether a pointer is incremented/decremented or an integersubscript is incremented/decremented. These are the patterns thatidentify a counted-plus and/or counted-minus:

Loop limited by Bound: the loop performs N repetitions where N is lessthan or equal to the Bound of p, and the pointer designates a sequenceof objects p through p + N − 1, or p through p − N + 1 Loop limited byHi: the loop increments an indirectable pointer until it is equal to HiLoop limited by Lo: the loop decrements an indirectable pointer until itis equal to Lo Loop limited by null terminator: the loop increments anindirectable pointer until its target is null

The SSCG 39 provides semantics for several attributes of pointers and/orsubscripts. The “_Sat” (“saturated”) semantics generatesmachine-dependent instructions or software code sequences such that thepointer or subscript never increments (or adds) higher than its Hivalue, and never decrements (or subtracts) lower than its Lo value. (Inother words, it is like a guage that “pegs” at its minimum and maximumvalues.) The “_Modwrap” semantics generates machine-dependentinstructions or software code sequences such that pointer and/orsubscript is wrapped modulo the End value. Therefore, as the pointer orsubscript is successively incremented, it runs from the Lo value to theHi value, then starts again at the Lo value. The “_Zerobound” semanticsgenerates machine-dependent instructions or software code sequences suchthat any fetch from outside the Lo-Hi limits (including the null-pointervalue) produces a zero value (or a default-initialized value for anon-scalar), and any store outside the Lo-Hi limits (including thenull-pointer value) produces a no-op. All three of these semantics canbe implemented in silicon A relaxation of _Zerobound permits delivery ofany unspecified value upon out-of-bounds fetch, while requiring a no-opfor out-of-bounds store. This relaxation permits greater optimization offetch operations: install an alternate service routine for the“segmentation” or “invalid address” trap to deliver a zero result to thecalling operation. In this alternative, there is no run-time penalty forany fetch instruction, even if bounds are not known at compile time.

If some control flow is too complicated and doesn't fit a simplecounted-plus or counted-minus pattern, and pointer-range attributesdon't guarantee safe fetch-or-store access and all other compile-timebounds-checks fail, then the SSCG 39 inserts executable bounds-checkcode. In the Safe Secure method there are two modes of bounds-checkcode. When the SSCG 39 is compiling in Debug mode, every attempt tofetch or store out of bounds, or to create a pointer value out of thefull range of values (which includes the one-too-far address), or tofetch-or-store through a null pointer, causes an invocation of an“unwind”, such as ss_unwind (which in an interactive debuggingenvironment causes an interactive breakpoint). In non-Debug mode, theSSCG 39 implements a choice among the following options: (a) use Debugsemantics; or (b) every attempt to fetch or store out of bounds producesa well defined result (either _Sat semantics, or _Modwrap semantics, or_Zerobound semantics) whichever produces the best fit to the currentoptimization profile (which might be “minimum code size” or “minimum CPUtime” or other). A warning should be generated to inform the programmer.In non-Debug mode, every attempt to create a pointer value out of thefull range of values produces an algebraically well-defined pointervalue, even though that value would not be usable for indirection orbounds-testing. Note that if a pointer has the Ntl (not-too-low)attribute, and as being dynamically compared against the Hi or Endvalue, the _Modwrap semantics will not be as efficient as the _Sat or_Zerobound semantics, because the latter semantics require only the Hi(or End) value to complete the bounds-checking. The same is true for apointer with the Nth (not-too-high) attribute and a Lo limit.

The selection between Debug mode and non-Debug mode is conditional upona switch set either at compile-time, at link-time (using an externalflag), at load time (using an environment variable), or during run-time(using an interactive debugger)

In both Debug and non-Debug mode, the SSDG 37 generates a warningmessage to inform the programmer that run-time bounds-checking has beeninserted by the Safe Secure Compiler 23.

The SSSA 35 provides a mechanism by which the programmer can requestthat, if the programmer believes that the control flow does in factguarantee adequate bounds checks, the original control flow iscommunicated to the organization which distributes the SSSA 35. Byincorporating this automated client feedback mechanism, saidorganization will have the opportunity to increase the set ofcounted-bounds control-flow contexts and Requirement-Guarantee patterns.To the extent that third-party organizations perform certification,validation, and/or branding of technology herein, said client feedbackis subject to the same third-party processes, since the assurances ofsafety and security provided by the Safe Secure method are dependentupon the correctness of the patterns that are accepted by the SafeSecure method.

The full set of bounds-enforcement mechanisms may produce a number ofinserted bounds-check code segments. As an optional Alternative, theSafe Secure method provides a further tool by which these bounds-checks(and the associated warnings) can be eliminated. Define an environmentalinteraction as a function invocation which produces a returned value orother state change which depends upon the external environment (such ascommand-line argument, input function, or getenv invocation). The SafeSecure method ensures that for every environmental interaction there isa guarantee that returned values and modified argument strings areeither bounded in size and value, or null-terminated. If unbounded butnull-terminated, the Safe Secure method requires that some boundingconstruct be imposed before use of the input value. (For example, apotentially very long command line argument can be converted into anumeric value by one of the string-to-numeric library functions, atwhich point the resulting value is bounded by the min and max of itstype.) Define all the segments of code in between environmentalinteractions as “pure code”. Use the incremental code-coverage method(Plum U.S. Pat. No. 5,758,061) to identify environmental interactionswhich precede code blocks which contain inserted bounds-check codesegments. Let the Safe Secure Compiler 23 insert checkpoint/restart codesegments at those environmental interactions. Now the environmentalinteractions can be simulated, using the minimum and maximum values forthe input, and/or using the complete range of values for the input, andthe pure code which follows those interactions can be executed in theenvironment of the full range of values for the input. Note that the setof input values must include any values which affect the control flowwithin the pure-code segment, and should also include the valuesone-less-than and one-greater-than these special values.

The static analysis necessary to determine bounds-checking need not beas aggressive as whole-program-optimization. The Safe Secure methodimposes upon programmers the requirement that each function containswithin its calling sequence and its control flow the guaranteesnecessary to assure that all fetches and stores are within bounds.Therefore, no entity larger than the function need be analyzed.Furthermore, good software design suggests that “proving” that eachfetch-or-store is valid should not require examination of hundreds oflines of code. If the validity is not already obvious, then theprogrammer should add such constructs as are required to make itobvious.

Note that the SSSA 35 must interact with the optimization analysisperformed in Semantic Analyzer 34. For a non-limiting example, theanalysis necessary to keep a pointer or an integer in a register(“aliasing logic”) may be required to determine that that pointer orthat integer retains its bounds-related attributes during specific arcsof the flow graph.

The methods described above for enforcing bounds safety have relied uponinsertion by the SSCG 39 of bounds-check code segments when stateanalysis is unable to determine the validity of fetch-or-store accesses.In an alternative method, the SSCG 39 inserts invocations of macros orinline functions in an intermediate representation of the originalprogram. For a non-limiting example, the following macros-or-functionscan be used:

_(——)csafe_fetch_hi(p, hi) *p if p<=hi _(——)csafe_fetch_end(p, end) *pif p<end _(——)csafe_fetch_loh(p, lo, hi) *p if p>=lo and p<=hi_(——)csafe_fetch_lob(p, lo, bound) *p if p>=lo and p<lo+bound_(——)csafe_fetch_lot(p, lo, tsize) *p if p>=lo and(char*)p<(char*)p+tsize _(——)csafe_store_hi(p, hi, val) *p = val ifp<=hi _(——)csafe_store_end(p, end, val) *p = val if p<end_(——)csafe_store_loh(p, lo, hi, val) *p = val if p>=lo and p<=hi_(——)csafe_store_lob(p, lo, bound, val) *p = val if p>=lo and p<lo+bound_(——)csafe_store_lot(p, lo, tsize, val) *p = val if p>=lo and(char*)p<(char*)p+tsize

Alternative names can be used, avoiding conflict with otherimplementation-defined names while reducing the length of the name.Efficient implementation of these macros (or inline functions) willdepend upon characteristics of the target implementation. The SSSA 35ensures that the pointer arguments in the macro invocations are namedvariables (which may be named temporaries introduced by the SSSA 35), sothat no side-effects (i.e. no increment, decrement, assignment, orfunction-call) are present in the macro argument expressions. In theevent that p is not in-bounds, the macro behaves in accordance with therequirements specified above for Debug and non-Debug mode.

Un-referenced auto storage is initially in the Unaliased state.Dynamically-allocated storage (via the C++ operator new, or malloc,etc.), and the pointer which is initialized by the allocationexpression, initially has the Unaliased attribute. If a reference to anobject, or a pointer, is assigned to another pointer within the sametranslation unit, both acquire the Visibly-Aliased attribute, and theSSSA 35 can record the full set of visibly-aliased pointers. If theaddress is passed to an external function, or assigned to an externalpointer, then the set of all visibly-aliased pointers acquires theOpaquely-Aliased attribute. If the function parameter, or the externalpointer, has the C99 “restrict” qualifier, then the SSSA 35 can requirethat the pointer was not Opaquely-Aliased prior to passing the argumentor assigning the pointer.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description buf c7.1.4 The pointer passed to a libraryfunction array parameter does not have a value such that all addresscomputations and object accesses are valid buf c6.5.6 An array subscriptis out of range, even if an object is apparently accessible with thegiven subscript (as in the lvalue expression a[1][7] given thedeclaration int a[4][5]) buf c6.5.6 Addition or subtraction of a pointerinto, or just beyond, an array object and an integer type produces aresult that points just beyond the array object and is used as theoperand of a unary * operator that is evaluated buf c7 An attempt ismade to copy an object to an overlapping object by use of a libraryfunction, other than as explicitly allowed (e.g., memmove) buf c6.5.8Pointers that do not point to the same aggregate or union (nor justbeyond the same array object) are compared using relational operatorsbuf c6.5.6 Pointers that do not point into, or just beyond, the samearray object are subtracted buf c6.5.6 Addition or subtraction of apointer into, or just beyond, an array object and an integer typeproduces a result that does not point into, or just beyond, the samearray object buf c6.3.2.1 An lvalue does not designate an object whenevaluated buf c7.19.6.1, An s conversion specifier is encountered by oneof the formatted output c7.24.2.1 functions, and the argument is missingthe null terminator (unless a precision is specified that does notrequire null termination) buf c7.19.6.2, A c, s, or [conversionspecifier is encountered by one of the formatted c7.24.2.2 inputfunctions, and the array pointed to by the corresponding argument is notlarge enough to accept the input sequence (and a null terminator if theconversion specifier is s or [) buf c7.21.1, A string or wide stringutility function is instructed to access an array c7.24.4 beyond the endof an object buf c6.7.3.1 A restrict-qualified pointer is assigned avalue based on another restricted pointer whose associated block neitherbegan execution before the block associated with this pointer, nor endedbefore the assignment buf c6.7.3.1 An object which has been modified isaccessed through a restrict- qualified pointer to a const-qualifiedtype, or through a restrict-qualified pointer and another pointer thatare not both based on the same objectApplying Pointer Analysis to Implementation-Generated Pointers [vptr]

In C++ there are object types which are restricted to the same simplesemantics as in C; these are known as the “plain old data” (POD) types.The C++ non-POD class (including struct) types have semantics that aremore complicated than the POD types. The process of constructing anon-POD object starts with the allocation (in static, stack, or heap) of“raw storage”; then the constructors of bases and members may modify thestorage, possibly involving virtual pointers (vptrs) and virtual tables(vtables). Only when all constructors have executed is the objectfully-constructed. A POD object is always “raw storage” because novirtual pointers or virtual tables are involved.

There are several situations that can produce undefined behaviors in C++that take place when the object is in the “raw storage” state. The SafeSecure Compiler (SSC) 23 can produce a fatal diagnostic when any ofthese situations occur (as listed in the table below).

There are only a few ways that a pointer to a non-POD class type T canreceive the address of something which is-not-a T. Variable-argumentlinkage is covered in the section “Variable argument list checking[varg]”. Any time an old-style cast or a reinterpret_cast converts to apointer-to-T, the SSC 23 can insert run-time checks to verify that thetarget is-a T.

When the target of a fetch is of pointer-to-function type (which for thepurposes of these methods includes pointer-to-member-function), thebehavior upon invalid fetch depends upon the Debug mode and thebounds-check semantics (_Modwrap, _Saturated, or _Zerobound). It wouldbe obvious to the Practitioner that if the fetch does not produce avalid pointer value, then the behavior will depend upon theDebug-vs-Non-Debug mode. In Debug mode, if any attempt is made to invokea function via an invalid pointer value, an “unwind” (such as ss-unwind)can be invoked, and the implementation may throw an exception of animplementation-defined type. In non-Debug mode, the result can be ano-op. Further obvious, in whichever semantics, if the pointer value isnull, that value is not a valid pointer value for function invocation.

Within one region of code analysis, where the compiler has completeknowledge of the Requirements and Guarantees associated with theimplementation-generated pointers, the compiler has adequate knowledgeto apply all the methods of the present method. However, when controlleaves that region of analysis (e.g. invocation of code which is“external”, i.e., unavailable to the compiler at compile-time, which mayinclude constructors, destructors, functions, and operations that couldraise exceptions), the compiler can ensure that implementation-generatedpointers are in the Maybe-indirectable state (i.e., either the pointeris null, or it points to valid data or code). In some cases, thecompiler understands that the addresses designated by the pointer isactually the pointer's value plus or minus some offset value which isvisible to the compiler; in these cases, the “Maybe-indirectable”property means “either the pointer value is null, or the pointer (asadjusted by the offset) is valid”. At any point where the compiler knowsthe value to be placed in the pointer, but does not yet know thevalue(s) to be placed in the offset(s), if “external” code must becalled, then the pointer value must be null before calling such code.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C++-Std# Description vptr 3.6.3 para 2 Flow of control passesthrough the definition of a previously destroyed local object vptr 3.8para 5 “Raw-storage” pointer is used as the operand of a delete -expression vptr 3.8 para 5 Non-POD in “raw-storage” state, and ptr isused to access a non-static data member vptr 3.8 para 5 Non-POD in“raw-storage” state, and ptr is used to call a non-static memberfunction vptr 3.8 para 5 Non-POD in “raw-storage” state, and ptr isimplictly converted to ptr to base vptr 3.8 para 5 Non-POD in“raw-storage” state, and ptr is used as operand of static_cast (withsome exceptions) vptr 3.8 para 5 Non-POD in “raw-storage” state, and ptris used as operand of dynamic_cast vptr 3.8 para 6 Lvalue designates anobject in “raw-storage” state, and lvalue-to- rvalue conversion(“fetch”) is applied to the lvalue vptr 3.8 para 6 Non-POD in“raw-storage” state, and lvalue is used to access a non static_datamember vptr 3.8 para 6 Non-POD in “raw-storage” state, and lvalue isused to call a non-static member function vptr 3.8 para 6 Non-POD in“raw-storage” state, and lvalue is implictly converted to ptr to basevptr 3.8 para 6 Non-POD in “raw-storage” state, and lvalue is used asoperand of static_cast (with some exceptions) vptr 3.8 para 6 Non-POD in“raw-storage” state, and lvalue is used as operand of dynamic_cast vptr3.8 para 8 Static or auto T has non-trivial dtor, and implicit dtortakes place when obiect is in “raw-storage” state vptr 3.8 para 9 Objectis created in the same storage that a static or auto const objectoccupies (or used to occupy) vptr 4.1 para 1 Lvalue of type T designatesan object which is-not-a T, and lvalue-to- rvalue conversion is appliedvptr 4.1 para 1 Lvalue of type T designates an object which isuninitialized, and lvalue-to-rvalue conversion is applied vptr 5.2.9para 5 Converting B lvalue to D lvalue, where the B object is not asub-object of a D object vptr 5.2.9 para 8 Converting B rvalue to Drvalue, where the B object is not a sub-object of a D obiect vptr 5.2.9para 9 Converting B ptr-to-member to D ptr-to-member, where the B objectis not a sub-object of a D object vptr 9.3.1 para 1 Object is-not-a X,and member of X is called on that object. vptr 10.4 para 6 Makingvirtual call to pure virtual function from ctor or dtor of abstractclass. vptr 12.4 para 14 Dtor is invoked for obiect whose lifetime hasended. vptr 12.6.2 para 8 Calling member functions, typeid, ordyanamic_cast from ctor- initializer before all mem-initializers forbase classes complete. vptr 12.7 para 1 For a non-POD, referring tononstatic member or base before ctor or after dtor. vptr 12.7 para 2Converting ptr-to-X to ptr-to-B before starting ctors of X and its Bbases or after completion of their dtors. vptr 12.7 para 2 Formingpointer to, or fetching value of, direct nonstatic member of objectbefore ctors start or after dtors complete. vptr 12.7 para 3 Virtualfunction call from ctor or dtor uses explicit class member access, butthe type is not the class (or base) of ctor (or dtor) vptr 12.7 para 4typeid is used in ctor or dtor, and static type of operand is not theclass (or base) of ctor (or dtor) vptr 12.7 para 5 dynamic_cast is usedin ctor or dtor, a nd static type of operand is not the class (or base)of ctor (or dtor)Iterative Method for Determining Requirements and Guarantees [iter]

The exemplary methods described above are implemented in the SSSA 35,which follows an interative method to be described in this section.(This section spells out in greater detail the steps described insection “Safe pointers [buf]” above.)

Each operation upon pointers, arrays, and/or subscripts may impose oneor more Requirements upon the preceding operations, declarations, and/orinitializations. Specific rules for inferring Requirements are shown inthe Safe Secure Interface Inference Table (“SSIIT”) 71. Each Requirementcauses the initiation of an upward search for the Guarantee thatsatisfies the Requirement.

Each operation, declaration, and/or initialization may produce one ormore Guarantees for subsequent operations. Each Guarantee persistsacross subsequent operations and statements until some subsequent eventterminates the Guarantee; such events include the end of the lifetime ofany objects in the Guarantee.

The steps itemized above can be performed in any order during thesemantic analysis. Each time that these steps are applied to the entiretranslation unit the SSSA 35 must determine whether progress was made,i.e. whether any new Guarantee was determined, or whether anyRequirement (not previously satisfied on previous iterations) is nowsatisfied. If an iteration covers the entire translation unit withoutmaking progress, then the SSSA 35 makes a list of all unsatisfiedRequirements. For each such Requirement, if it is capable of link-timeresolution, then entries are created in the SSBDF 26 so that it can beresolved or diagnosed at link-time. Otherwise, if the Requirement iscapable of run-time prevention (using _Sat or _Modwrap or Zeroboundlogic), then the SSCG 39 generates one of the appropriate code sequencesas described above. If none of these link-time or run-time resolutionsare available then the SSDG 37 issues a diagnostic. If the code whoseRequirement cannot be satisfied occurs in a code region which can neverbe executed (i.e. “dead code”) or is not executed in this application(i.e. “sleeper code”), then the implementation is permitted to treat thediagnostic as a warning. In any other context, the “unsatisfiedRequirement” diagnostic must prevent production of object code.Furthermore, if the unsatisfied Requirement occurs in sleeper code, thenthe SSSA 35 makes notations in the SSBDF 26 to indicate that the codecannot be safely invoked, and the SSCG 39 generates a stub whichsatisfies the linkage requirements and produces safe behavior in Debugor non-Debug mode.

Any Requirement of “at least enough” or “no more than” can be satisfiedby a Guarantee that is more strict than the Requirement.

These Requirement-Guarantee patterns are intended to reflect the basics,as understood by all Practitioners, of objects in machine memory, memoryaddressing, and aliasing rules. The patterns illustrated below arenon-limiting examples.

Acknowledging the risk of redundancy, the Requirement-Guarantee patternsare itemized in the lists below. The first list itemizes the patternsthat were defined in the Preliminary Application.

-   -   1. If the SSSA 35 has identified a Requirement that a pointer p        is non-null, and if the current control flow proceeds from a        non-null arc of a pointer test, then the non-null arc provides        the necessary Guarantee.    -   2. If the SSSA 35 has identified a Requirement that a pointer,        array, and/or subscript has attributes Qi, I, Nth, Ntl, End, Lo,        or Hi, then various relevant Guarantees are found in Safe Secure        Pointer Attribute Hierarchy 41 (see FIG. 7).    -   3. If the SSSA 35 has identified a Requirement that a pointer or        array has the Nullterm attribute, then various relevant        Guarantees are found in the paragraph “To determine the state        transition for the Nullterm attribute” in section “States of        objects [stat”.    -   4. If the SSSA 35 has identified a Requirement that an integer        is usable as a subscript for array A, and if        BOUND_OF(B)<=BOUND_OF(A), and if the integer is usable as a        subscript for array B, then this provides the needed Guarantee.    -   5. If the SSSA 35 has identified any bounds Requirement after        invocation of a C and C++ standard library function (such as        “ptr=malloc(n)”), then the Guarantee may be provided by        semantics of that function (such as “TSIZE_OF(ptr) is n”) as        specified in its entry in the SSBDF 26.    -   6. If the SSSA 35 has identified a bounds Requirement for a        pointer which is visible to the SSSA 35 as a heap-allocated        pointer, then a run-time Guarantee can be provided that uses        bounds data from the argument(s) to the heap allocation.    -   7. If the SSSA 35 has identified any bounds Requirement for an        array defined in the current translation unit, the bounds        Guarantee is immediately available to the SSSA 35 from the        defining declaration.    -   8. If the SSSA 35 has identified any bounds Requirement        involving a subscript or pointer within the body of a        counted-loop (counted-plus or counted-minus loop), then the        bounds Guarantee is given by that counted-plus or counted-minus        loop.

This second list itemizes additional patterns:

-   -   1. If the SSSA 35 has identified a Requirement that, for some        limit LIM, 0<=i<LIM, and we have a bounding loop for (i=0;        M*i<N; ++i), then the loop provides a Guarantee that LIM=N/M.    -   2. If the SSSA 35 has identified a Requirement that the Tsize of        pointer p is at least N (in other words, the bytes from *p to        *(p+N−1) are all within one object), and if p loops from a        upwards to b, then the Requirement is satisfied for all p iff it        is satisfied for the maximum value, b.    -   3. If the SSSA 35 has identified a Requirement that some        property is true when N+c reaches its maximum value (where N is        independent of c), then the Requirement is satisfied when c        reaches its maximum value.

For a non-limiting example consider the following source program for arudimentary storage allocator:

static char a[N]; static char *p = a; void * my_alloc(size_t n) {   char*ret = p;   char *lim;   if (n == 0) n = 1;   lim = p + n;   if (n > N ∥lim > a+N) return (void*)0;   else {     p = lim;     return (void*)ret;  } }

As per the definition of the iterative method, the determination ofRequirements and Guarantees can proceed in any order. For a non-limitingexample, start with those Requirements and Guarantees that require noflow analysis. The static declarations indicate that the Bound of a isN, and that p is initialized to the same bounds as a. The expression a+Ndesignates the End of a. On the false (“else”) arc, lim has Nth or Endattribute, as determined by the SSPAPT 51, and ret has whateverattributes p had on entry to my_alloc. Then flow analysis determinesthat p is never decremented, that no external code can modify it(because of the file-scope static), and that it is incremented only byan unsigned value which is guaranteed not to “wrap-around” the addressspace. Therefore, p is never less than its initial value, the Lo of a.The function performs no fetch-or-store operations using pointers orsubscripts. Therefore, the SSSA 35 needs only to determine theattributes of the returned value. On one arc the returned value is null.On the “else” arc the returned value is at least Indirectable, because pis always strictly less than a value (lim) which is Nth or End. Then theSSSA 35 determines the bounds of the returned value. The returned valueis a pointer into array a, so the End of p is the End of a, but theattributes of array a are not visible outside the source file ofmy_alloc and therefore cannot be used to define the bounds. The onlyexternally-visible object involved in my_alloc is the parameter n. TheSSSA 35 can guarantee that the Tsize of the returned value is at leastn, because p+n is at most equal to the End of a. The Tsize cannot begreater than n, because p+n can be equal to the End of a. Therefore theSSSA 35 enters into the SSBDT 61 an entry for my_alloc as follows:

QI TSIZE_IS(n) my_alloc(n)

Note that if the array a had been declared extern instead of static, theentry for my_alloc would instead specify “QI SUB4(a)”. The programmercan use one of the alternative methods as defined in [0104] to indicatean intention to restrict the return attributes to “QI TSIZE_IS(n)” (orchange the “extern” back to “static”, of course).

As a further example consider the source code for an implementation ofthe standard C and C++ library function strlen:

size_t strlen(const char *str) {   size_t n = 0;   while (*p++ != ‘\0’)    ++n;   return n; }

Because it contains a fetch using p, the SSSA 35 determines that theRequirement upon p is at least an Indirectable requirement. Because *pis never modified (consistent with the “const” qualifier), and nodeallocation is performed upon p, the Indirectable Requirement is also aGuarantee. The pattern of the loop determines the stronger NulltermRequirement, which is also a Guarantee. The relationship between theparameter and the returned value is also dictated by the pattern of theloop. The inference of Requirements and Guarantees produces thefollowing entry into the SSBDT 61:

strlen(str NULLTERM LENGTH_IS(return) )

Consider a situation in which the programmer had explicitly indicatedconflicting annotations; for example NULL, or QI, or TSIZE_IS(return).It is a requirement of the Safe Secure method that a diagnostic messageshall be produced by the SSDG 37 to call the conflict to the attentionof the programmer.

The components of the Safe Secure Linker are shown in FIG. 11. As iscommon in the art, the Safe Secure Linker (“SSL”) 28 reads ObjectFile(s) 25, creating a Symbol Table 81 of symbols provided and symbolsneeded. The Link-Time Symbol Resolver 83 determines the addresses of thesymbols which will be loaded in the executable image. If any symbols areneeded but not provided (or if typesafe linkage fails in C++), then theLink Diagnostic Generator 85 produces a message, as is customary in thecommon art. The Safe Secure Linker 28 provides further methods beyondthe common art. Along with each Object File 25 and/or DynamicLink-Library 27, Safe Secure Compiler 23 produced a SSBDF 26 containingRequirements and Guarantees. The Safe Secure Linker 28 reads theSSBDF(s) 26 which accompany the Object File(s) 25 being linked. Each“undefined symbol” entry in the Symbol Table 81 is augmented in the SafeSecure Bounds Data Symbol Table (“SSBDST”) 82 with the Requirements andGuarantees provided by the various code contexts that require thesymbol. Each “defined symbol” entry in the Symbol Table 81 is augmentedaugmented in the Safe Secure Bounds Data Symbol Table (“SSBDST”) 82 withthe Requirements and Guarantees provided by the defining instance ofthat symbol. The Safe Secure Link-Time Analyzer (“SSLTA”) 84 performsthese tests:

-   -   1. For each function-call linkage context, each Requirement of        the called function is satisfied by a Guarantee in the calling        function.    -   2. For each external array or pointer linkage context, each        Requirement in one object file is satisfied by a Guarantee in        the other object file.

Any unsatisfied Requirement causes a fatal diagnostic from the SafeSecure Link Diagnostic Generator (“SSLDG”) 86; this prevents theproduction of any executable program.

As a further example we present part of the analysis of one program fromthe SPEC benchmarks. We chose to test the Safe Secure method with ahand-simulation on one complete application. Of the 12 different apps inSPEC CINT2000, the smallest is “256.bzip2”, which contains about 4600lines of code in two C source files (spec.c and bzip2.c). The smallerfile (spec.c) contains about 36 fetch-or-store instances and the largerfile (bzip2.c) contains about 250 fetch-or-store instances. The examplebelow shows the first 8 instances of fetch-and-store operations inspec.c.

int spec_init ( ) {  int i, j;  debug(3,“spec_init\n”);  /* Clear thespec_fd structure */  /* Allocate some large chunks of memory, we cantune this later */  for (i = 0; i < MAX_SPEC_FD; i++) {   int limit =spec_fd[i]/*1*/.limit;   memset(&spec_fd[i], 0, sizeof(*spec_fd/*2*/));  spec_fd[i].limit = limit;   spec_fd[i].buf = (unsigned char*)malloc(limit+FUDGE_BUF);   if (spec_fd[i].buf == NULL) {    printf(“spec_init: Error mallocing memory!\n”);    exit(1);   }   for (j = 0;j < limit; j+=1024) {    spec_fd[i].buf[j]/*3*/ = 0;   }  }  return 0; }int spec_random_load (int fd) {  /* Now fill up the first chunk withrandom data, if this data is truly   random then we will not get much ofa boost out of it */ #define RANDOM_CHUNK_SIZE (128*1024) #defineRANDOM_CHUNKS (32)  /* First get some “chunks” of random data, becausethe gzip   algorithms do not look past 32K */  int i, j;  charrandom_text [RANDOM_CHUNKS]  [RANDOM_CHUNK_SIZE];  debug(4,“CreatingChunks\n”);  for (i = 0; i < RANDOM_CHUNKS; i++) {   debug1(5,“CreatingChunk %d\n”, i);   for (j = 0; j < RANDOM_CHUNK_SIZE; j++) {   random_text[i]/*4*7[j]/*5*/ = (int)(ran( )*256);   }  } debug(4,“Filling input file\n”);  /* Now populate the input “file” withrandom chunks */  for (i = 0 ; i < spec_fd[fd]/*6*/.limit; i+= RANDOM_CHUNK_SIZE) {   memcpy(spec_fd[fd].buf + i, /*7*/    random_text[(int)(ran( )*RANDOM_CHUNKS)]/*8*/,    RANDOM_CHUNK_SIZE);  }  /* TODO-REMOVE: Pretend we only did 1M */ spec_fd[fd].len = 1024*1024;  return 0; }

Eight instances of fetch-or-store operations are marked in the codesample above. Here is the analysis of Requirements and Guarantees forthese eight marked instances:

1. spec_fd[i] Requires: i IS_SUBSCRIPT_FOR(spec_fd)

Searching for the Guarantee to meet this Requirement, we search up tothe for-loop. The for-loop is a counted-plus which guarantees that i isless than MAX_SPEC_FD. MAX_SPEC_FD is 3, so the maximum value of i is 2,which is the highest subscript for the spec_fd array. Therefore, iIS_SUBSCRIPT_FOR(spec_fd). (We can abbreviate this as “iSUB4(spec_fd)”.) So Requirement 1 is satisfied by the counted-plus loop.

Note a series of occurrences of the same expression (spec_fd[i]) whichare satisfied by the same Guarantee, so this by-hand analysis won'tre-state the previous process.

2: *spec_fd Requires: (nothing)

This expression (*spec_fd) looks like an indirection but it isn't; it'sjust syntax for the size of one element of spec_fd. Because sizeofdoesn't evaluate its argument, there is no fetch-or-store. Therefore,there is really no Requirement here.

3: spec_fd[i].buf[j] Requires: j SUB4(buf)

Search up to the for-loop. The loop is monotone increasing, so thelargest value for j is limit-1. In how many places is buf initialized?Only one, 6 lines earlier. The malloc initialization guarantees thatTSIZE_OF(spec_fd[i].buf) is greater than limit. So Requirement 3 issatisfied.

4: random_text[i] Requires: i SUB4(random_text)

This one is trivial. The “for i” loop runs i to RANDOM_CHUNKS−1, whichis the Hi of random_text. So Requirement 4 is satisfied.

5: random_text[i][j] Requires: j SUB4(random_text[i])

Also trivial; see the “for j” loop to the Hi of random text[i].Therefore Requirement 5 is satisfied.

6: spec_fd[fd] Requires: fd SUB4(spec_fd)

Searching upward in the spec_random_load function, nothing provides theneeded Guarantee, so the Requirement becomes a Requirement of thefunction. Using the “bounds-data file” notation, the requirement is

-   -   spec_random_load(fd SUB4(spec_fd) )

It appears that this spec_random_load function is never called in thisapplication, so this Requirement never propagates.

7: memcpy(-, -, RANDOM_CHUNK_SIZE) Requires: see below

The “bounds-data” file entry for memcpy will look like this:

-   -   memcpy(s, p, n IS_TSIZE_OF((s,p)))

Therefore, there are two parts to this Requirement 7:

-   -   Requirement 7a: TSIZE_OF(spec_fd[fd].buf+i) is RANDOM_CHUNK_SIZE    -   Requirement 7b: TSIZE_OF(random_text[(int)(ran(        )*RANDOM_CHUNKS)]) is RANDOM_CHUNK_SIZE

The Tsize of the first argument is the number of bytes fromspec_fd[fd].buf+i to the last byte of spec_fd[fd].buf. This number ofbytes reaches its minimum (its tightest constraint) when spec_fd[buf]+ireaches its maximum value. The maximum value of spec_fd[fd].buf+i isreached when i reaches its maximum value, namely spec_fd[fd].limit. Therelationship between spec_fd[fd].buf and spec_fd[fd].limit isestablished in the function spec_init: TSIZE_OF(spec_fd[i].buf) isspec_fd[i].limit+FUDGE_BUF.

Therefore Requirement 7a is equivalent to

spec_fd[i].limit + RANDOM_CHUNK_SIZE <= spec_fd[i].limit + FUDGE_BUFwhich simplifies to

RANDOM_CHUNK_SIZE <= FUDGE_BUF

But RANDOM_CHUNK_SIZE is 128*1024, and FUDGE_BUF is 100*1024. ThereforeRequirement 7a cannot be satisfied without changes to the source code.(For example, FUDGE_BUF could be increased to the same value asRANDOM_CHUNK_SIZE.) Note that this unsatisfiable Requirement occursinside “sleeper code”, i.e. code which is not executed in thisapplication. A compiler which is being tested by SPEC would in alllikelihood not give fatal diagnostics for dead code and sleeper code,and would compile and execute the application despite the unsatisfiableRequirement 7a in the sleeper-code function spec_random_load. Theresulting executable program is still certifiably free from bufferoverflows.

The Tsize of each row of the random_text array is RANDOM_CHUNK_SIZE, asgiven by the declaration of random_text; therefore Requirement 7b istrivially satisfied.

8: random_text[(int)(ran()*RANDOM_CHUNKS)] Requirement: see below

Requirement 8 is that (int)(ran( )*RANDOM_CHUNKS) must be usable as asubscript for random_text; i.e.

-   -   (int)(ran( )*RANDOM_CHUNKS SUB4(random-text).

From the declaration of random_text, its Bound is RANDOM_CHUNKS.Therefore Requirement 8 requires

-   -   0        (int)(ran( )*RANDOM_CHUNKS)<RANDOM_CHUNKS or    -   0        ran( )<1.0

This imposes a Requirement upon the ran( ) function (not shown in thisexample). Determining at compile-time that ran( ) actually produces anonnegative result smaller than 1.0 is beyond the scope of the SafeSecure Requirement-Guarantee patterns at compile time. Therefore theSafe Secure Compiler 23 must analyze the options for run-time checking,namely _Sat, _Modwrap, and _Zerobound. Let T1 designate the temporaryresult of calculating the subscript (int)(ran( )*RANDOM_CHUNKS). SinceRANDOM_CHUNKS is a constant (32), the code generation for the run-timechecking is as follows:

_Sat random_text[0 > T1 ? 0 : (31 < T1 : 31 : T1)] _Modwraprandom_text[T1 % 32] _Zerobound (0 > T1 : dummy : (31 < T1 : dummy :random_text[T1])Since this particular example arises in a SPEC benchmark, the compilerwill probably favor optimization for speed. Because the modulus is aconstant power of two, the compiler will in all likelihood recognize aspecial-case pattern in the _Modwrap alternative and generate theplatform-dependent optimized version, which typically looks likerandom_text[T1 & 0x1F].

The SSSA 35 can determine additional states for pointers in C++. If thepointer is produced by an array new-expression, then it acquires theArray-New attribute. If the pointer is produced by a scalarnew-expression, then it acquires the Scalar-New attribute. Atcompile-time, or at link-time, the delete array expression requires apointer with the Array-New attribute, and the static type of the pointermust be identical to the dynamic type. At compile-time, or at link-time,the delete scalar expression requires a pointer with the Scalar-Newattribute, and the static type of the pointer must be identical to thedynamic type, or else the static type is a base class of the dynamictype and the static type has a virtual destructor.

The SSSA 35 attaches certain attributes to types in certain situations.If a class type is an incomplete type at the point where an object ofthat type is deleted, then the Incomplete-at-deletion attribute isattached to the class type. At the point in compilation when the classtype is completed, the SSSA 35 verifies that the complete class typedoes not contain a non-trivial destructor or deallocation function;otherwise, a fatal diagnostic is issued.

When a member, or destructor, is invoked for an object, the compiler candetermine (usually but not always) whether the type of that object isappropriate for that member (or destructor). The context in which themember or destructor is invoked imposes a Requirement on the pointervalue used in that context. This Requirement is then propagated upwardto meet an appropriate Guarantee; if the upward propagation stops at afunction parameter list, then the Requirement is added to the link-timeRequirements of that function. If the compile-time or link-time testscannot resolve the Requirement with a Guarantee, then a fatal diagnosticcan be produced.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C++-Std# Description Iter 5.3.5 para 2 In delete object expression,operand is not pointer to non-array object or a base-class subobjectIter 5.3.5 para 2 In delete array expression, operand is not the pointervalue from previous array new-expression Iter 5.3.5 para 3 In deleteobject expression, static type is different from dynamic type, andstatic type is not a base class of dynamic type Iter 5.3.5 para 3 Indelete object expression, static type is different from dynamic type,and static type does not have a virtual destructor Iter 5.3.5 para 3 Indelete array expression, static type is different from dynamic type Iter5.3.5 para 5 Object being deleted has incomplete class type at point ofdeletion, and complete class has non-trivial dtor or deallocationfunction Iter   5.5 para 4 Dynamic type does not contain the pointed- tomember. Iter 12.4 para 12 Object is-not-a X, and dtor of X is called onthat object.Special Requirements for Special Functions [funcs]

A function is determined to be a signal handler if its address is passedto the signal function; this imposes a set of Requirements called“signal-handler Requirements” on the function. Any function called by ahandler also gets marked for the signal-handler Requirements. TheseRequirements require that the function does not modify any object whosetype is not std::sig_atomic_t or whose cv-qualifier(s) do not includevolatile.

In the function-try-block of a constructor or destructor, any directreference to a non-static member of a base class can be diagnosed atcompile time. Any fetch or store via pointers imposes a Requirement uponthe pointer that it does not refer to a non-static member of a base.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C++-Std# Description funcs  1.9 para 9 After receipt of a signal,the value of any object not of volatile std::sig_atomic_t is modified bythe handler funcs 15.3 para 11 Referring to non-static member of base inhandler for fn-try-block of ctor or dtor (overtly or via pointer values)Bitwise Manipulation of Pointers [bitp]

If the low-order bits of a pointer are masked OFF or ON by acompile-time constant mask, and if that mask specifies a value smallerthan the alignment requirement of the pointed-to type, then thepointer-bound-state of the pointer is not altered thereby. In all othercases, the pointer-bound-state of the pointer is indeterminate (Unk)after manipulation. Reading a pointer from external store (via % p,fread, or other method) produces the indeterminate pointer-bound-state

The range of unsigned integer values can in one exemplary implementationbe sufficient to represent the difference of any two pointers, as wellas sufficient to represent unambiguously the value of any pointer.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description bitp c6.3.2.3 Conversion of a pointer to aninteger type produces a value outside the range that can be representedbitp c7.19.6.2, The input item for a % p conversion by c7.24.2.2 one ofthe formatted input functions is not a value converted earlier duringthe same program executionVariable Argument List Checking [varg]

A compiler 23 configured for the Safe Secure method can in one exemplaryillustrative non-limiting implementation produce special assistance forinvocation of functions declared with ellipsis (“variable-argumentfunctions”). At each invocation, the Safe Secure Compiler 23 is aware ofthe promoted types of the actual arguments, and can in one exemplaryimplementation produce a null-terminated string containing thename-mangled representation of the promoted arguments. (For adescription of a typical name-mangling algorithm, see e.g., MarkMitchell et al., “Itanium C++ ABI”(http://www.codesourcery.com/cxx-abi/abi.html)) The Safe Secure Compiler23 can in one exemplary implementation provide special handling of theva_arg macro as defined in header <stdarg.h> as follows: If the typeargument is a scalar type which produces a one-byte encoding in themangled name string (e.g. double, which produces the single character‘d’ in typical name-mangling, then an invocation such as

p = va_arg(ap, double);produces a translated invocation such as

p = _va_arg3(ap, double, ‘d’);

The enhanced _va_arg3 macro can in one exemplary implementation testthat the next byte in the argument mangled-name string is the character‘d’, incrementing the pointer after the test. If the test is false, anassociated “match” function is invoked, such as

_va_arg_double_match(&ap);

The rules for type-matching for variable-argument functions permit morematches than the strict same-type rules of C++; refer to section [tsl].If the argument mangled-name character fails the type-matching rulesdescribed there, then a run-time error is reported by using thess_unwind function.

If at compile-time, a va_list (e.g. ap) is (1) passed as an argument toanother function, (2) passed in that function to the va_arg macro, and(3) also passed to the va_arg macro in the original function, then theSafe Secure Diagnostic Generator (“SSDG”) 37 can produce a fataldiagnostic. At run-time, in Debug mode, if the macro va_arg is invokedusing the parameter ap that was passed to a function that invoked themacro va_arg with the same parameter, an “unwind” (such as ss_unwind)can be invoked, and the implementation may throw an exception of animplementation-defined type. At run-time in non-Debug mode, in thissituation the behavior can be an implementation-defined choice betweenproducing the next value in sequence from where the called function leftoff, or the next value in sequence ignoring any accesses performed inthe called function. That is, the va_list information can be containedin the ap object which was passed to the called function, or the va_listinformation can in some way be pointed to by the ap object.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description varg c7.15.1.1 The va_arg macro is invoked whenthere is no actual next argument, or with a specified type that is notcompatible with the promoted type of the actual next argument, withcertain exceptions varg c7.15 The macro va_arg is invoked using theparameter ap that was passed to a function that invoked the macro va_argwith the same parameter varg c7.15.1.4 The va_start macro is called toinitialize a va_list that was previously initialized by va_start (orva_copy in c99) without an intervening invocation of the va_end macrofor the same va_list varg c7.19.6.8, c7.19.6.9, c7.19.6.10, Thevfprintf, vfscanf, vprintf, vscanf, vsnprintf, c7.19.6.11, c7.19.6.12,c7.19.6.13, vsprintf, vsscanf, vfwprintf, vfwscanf, vswprintf,c7.19.6.14, c7.24.2.5, c7.24.26, vswscanf, vwprintf, or vwscanf functionis . . . c7.24.2.7, c7.24.2.8, c7.24.2.9, c7.24.2.10 varg c7.19.6.8,c7.19.6.9, c7.19.6.10, . . . called with an improperly initializedva_list c7.19.6.11, c7.19.6.12, c7.1 9.6.13, argument, or the argumentis used (other than c7.19.6.14, c7.24.2.5, c7.24.2.6, in an invocationof va_end) after the function c7.24.2.7, c7.24.2.8, c7.24.2.9, returnsc7.24.2.10Type-Secure Linkage [tsl]

In the Safe Secure method, C functions are type-checked using animplementation mechanism similar to that used for C++. This does notintroduce overloading in C; the underlying function-name identifier mustbe unique for each C function. The rules for matching the type of Cfunctions also permit linkage of functions whose signature differs fromthe expected type by the rules of “same representation and alignment”(see [13] 6.2.5). For example, on many implementations, therepresentation of the long double type is actually the samerepresentation as the double type, i.e., a 64-bit floating pointrepresentation. The test for “same representation and alignment” extendsto pointers, both for the pointer value itself and for the typepointed-to. Pointer-to-character (signed, unsigned, or unspecified) iscompatible with pointer-to-void. The reason for using the relaxed rulesof “same representation and alignment” rather than the strict “sametype” rules is to avoid negative responses from today's C and C++programmers, who are currently accustomed to “practical” rather than“pedantic” standards for proper behavior of variable-argument functions.Portability is often important, but portability cannot over-ride therequirements of safety and security. (An alternate name for “type-securelinkage” is “type-compatible linkage”).

The type-secure linkage rules apply to data as well as to functions.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description tsl c6.2.7 Two declarations of the same objector function specify types that are not compatible tsl c6.3.2.3 A pointeris used to call a function whose type is no compatible with thepointed-to type tsl c6.5.2.2 A function is defined with a type that isnot compatible with the type tsl c6.9 An identifier with externallinkage is used, but in the program there does not exist exactly oneexternal definition for the identifier, or the identifier is not usedand there exist multiple external definitions for the identifier tslc7.1.4 An argument to a library function has an invalid value or a typenot expected by a function with variable number of argumentsMode Strings for fopen [fopen]

If at compile-time the string pointed to by the mode argument in a callto the fopen function does not exactly match one of the expectedcharacter sequences a fatal diagnostic message can be produced. If theerror occurs at run-time in Debug mode, ss_unwind can be invoked; theimplementation may throw an exception of an implementation-defined type.If the error occurs at run-time in non-Debug mode, the implementationcan ignore all unrecognized portions of the mode argument.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description fopen c7.19.5.3 The string pointed to by themode argument in a call to the fopen function does not exactly match oneof the specified character sequencesDigital Signatures for all Components [digsig]

Safety and security are compromised when compiler components (such assystem header files) do not contain the approved unmodified sources asreleased and installed. The Safe Secure method requires that the SafeSecure Compiler 23 provides one menu choice, or one command-lineinvocation, which tells the user whether the components of the SafeSecure Compiler 23 (including executable programs, library object files,and system headers) have been altered (whether deliberately orinadvertently) from their initial state as delivered. The specificmechanism for such verification is left to the vendor's choice, andseveral mechanisms (such as checksums and digital signatures) arewell-known in the current art. Furthermore, during each compilation, thefirst time each header (or other component) is opened for reading, thesame checking of that header takes place. The same checking is alsoperformed for all library components referenced at link-time.

The Safe Secure Compiler 23 produces the Safe Secure Inputs Check-List(“SSICL”) 24, a list of the file-names (or equivalent designation) ofall the source components which were read by the compiler during thecompilation of one or more outputs. In addition to each file-name, theSSICL 24 also contains one or more checksums for the contents of thecorresponding component (The term “check-list” is used here to designatea list of names and checksums.) At least one of the checksums embodiesthe following method of forming the checksum:

-   -   1. Text files represented in ASCII, ISO 646, ISO 8859-1        (“Latin-1”), or the UTF-8 encoding of Unicode or ISO 10646, are        checksummed using the values of that encoding. Otherwise, each        text file is converted to the UTF-8 form of ISO 10646 before        checksumming.    -   2. Each sequence of whitespace (except in literals) is replaced        by one Space character before checksumming.    -   3. On each instance of the word “return” (except in        double-quoted string literals) followed by one or more        occurrences of the Space character or the Open Parenthesis        character, any parentheses around the returned expression are        removed before forming the checksum. As an alternative, the        return statement is not treated specially, but any tabs or        spaces appearing after a line-feed are checksummed individually        rather than being condensed into one space character before        checksumming.    -   4. No other transformations are applied to the source        characters.

The SSBDF 26 contains a similar check-list listing each output fileproduced by the compiler (object file, executable file, or dynamiclink-library), together with one or more checksums. At least one of thechecksums embodies the method given above, using the actual 8-bit valueof each byte as an unsigned character value (from 0 to 255). Thischeck-list includes one entry designating the SSICL 24, including theone-or-more checksums formed in the same way as specified above for theentries contained in the SSICL 24.

Also contained in the SSBDF 26 is a list of checksums known as theCompilation Signature, formed as follows. At the N^(th) occurrence of acompiler operation specified by the Safe Secure method (e.g., theinference of an attribute, or the satisfying of a Requirement by aGuarantee), the SSC 23 forms a checkum of the operand(s) of thatoperation. This checksum is stored as the first entry on the CompilationSignature list. Repeat this process at the 2*N^(th) operation, the4*^(th) operation, the 8*N^(th) operation, etc. The resulting list ofchecksums in the Compilation Signature is of a size roughly proportionalto the base-2 logarithm of the program size. This Compilation Signatureprovides a record of the compilation of a specific program by a specificSafe Secure Compiler 23.

Distinctive Marking of Validated Applications [mark]

The SSC 23 and SSL 28 can insert code to implement the authenticationmethod defined in U.S. Pat. No. 5,579,479; therefore, after anapplication has been successfully compiled and linked according to themethods described in the present invention, the executable applicationperforms its start-up in a specific fashion.

Format Strings for Printf Scanf, Strftime Functions [fmt]

If at compile-time the string pointed to by the format argument in acall to any of the printf/scanf functions does not match the number andtypes of the actual arguments, a fatal diagnostic message can beproduced (as is well-known in current art). If the format string is arun-time character string (i.e., not a compile-time string), noadditional argument-checking is required beyond the type-checkingperformed for variable argument lists (see section “Variable argumentlist checking [varg]”).

If at compile-time the string pointed to by the format argument in acall to the strftime function does not exactly match one of the expectedcharacter sequences a fatal diagnostic message can be produced. If theerror occurs at run-time, ss_unwind can be invoked; the implementationmay throw an exception of an implementation-defined type.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description fmt c7.19.6.1, c7.19.6.2, An invalid conversionspecification is found in the format for c7.23.3.5, c7.24.2.1, one ofthe formatted input, coutput functions, or the strftime c7.24.2.2,c7.24.5.1 or wcsftime function fmt c7.19.6.1, c7.19.6.2, An n conversionspecification for one of the formatted input, c7.24.2.1, c7.24.2.2coutput functions includes any flags, an assignment- suppressingcharacter, a field width, or a precision fmt c7.19.6.1, c7.19.6.2, Thereare insufficient arguments for the format in a call to c7.24.2.1,c7.24.2.2 one of the formatted input, coutput functions, or an argumentdoes not have an appropriate type fmt c7.19.6.1, c7.19.6.2, A conversionspecification for one of the formatted input, c7.24.2.1, c7.24.2.2coutput functions uses a length modifier with a conversion specifierother than those described fmt c7.19.6.1, c7.24.2.1 A conversionspecification for a formatted output function uses an asterisk to denotean argument-supplied field width or precision, but the correspondingargument is not provided fmt c7.19.6.1, c7.24.2.1 In a call to one ofthe formatted output functions, a precision appears with a conversionspecifier other than those described fmt c7.19.6.1, c7.24.2.1 Aconversion specification for a formatted output function uses a # or 0flag with a conversion specifier other than those described fmtc7.19.6.2, c7.24.2.2 The result of a conversion by one of the formattedinput functions cannot be represented in the corresponding object, orthe receiving object does not have an appropriate typeFunction Invocation Patterns [invoc]

Some functions in the standard C and C++ library return nothing (the“void” functions). Other functions always return a value with nosuccess-or-fail status information. Some functions return a value whichprovides status information. The C library exhibits a ratherinconsistent set of status-returning patterns. Here is a list of thevarious patterns of status-returns for standard C and C++ functions:

-   -   a. boolean (nonzero is success): setjmp, the character        classification functions (7.1.4), feof, ferror, mblen(with null        s), mbtowc(with null s), wctomb(with null s), mbsinit, wide        character classification functions (7.25.2.1)    -   b. null is failure: setlocale, tmpfile, tmpnam, fopen, freopen,        fgets, gets, calloc, malloc, realloc, getenv, bsearch, memchr,        strchr, strpbrk, strrchr, strstr, strtok, gmtime, localtime,        fgetws, wcschr, wcspbrk, wcsrchr, wcsstr, wcstok, wmemchr    -   c. SIG_ERR is failure: signal    -   d. zero is success: raise, rename, fclose, setvbuf, fgetpos,        fseek, fsetpos, atexit    -   e. EOF is failure: fflush, fgetc, fputc, fputs, getc, getchar,        putc, putchar, puts, ungetc, fputws, wctob    -   f. negative is failure: fprintf, printf, sprintf, vfprintf,        vprintf, vsprintf, fwprintf, swprintf, vfwprintf, vswprintf,        vwprintf, wprintf    -   g. number of items transmitted: fscanf, scanf, sscanf, vfscanf,        vscanf, vsscanf, fread, fwrite, fwscanf, swscanf, vfwscanf,        vswscanf, vwscanf, wscanf    -   h. nonnegative and less than n: snprintf, vsnprintf    -   i. negative one is failure: ftell, mblen(with non-null s),        mbtowc(with nonnull s), wctomb(with nonnull s), mbstowcs,        wcstombs, clock, mktime, time, wcrtomb, mbsrtowcs, wcsrtombs    -   j. high-low-equal: memcmp, strcmp, strcoll, stmcmp, fwide,        wcscmp, wcscoll, wcsncmp, wmemcmp    -   k. greater than n is failure: strxfim, wcsxfrm    -   l. [reserved—no L]    -   m. zero is failure: strftime, wcsftime    -   n. WEOF is failure: fgetwc, fputwc, getwc, getwchar, putwc,        putwchar, ungetwc, btowc    -   o. minus two through n: mbrlen, mbrtowc

In each of the calling contexts listed above, there is a special“comparison value” against which the returned value should be tested.For cases 1, 2, 4, 6, 10, and 12, the comparison value is zero. For case3, the comparison value is SIG_ERR. For case 5, the comparison value isEOF. For cases 7 and 11, the comparison value is a value unambiguouslydetermined by the list of arguments. For case 8, the comparison valuecan be either zero or a value unambiguously determined by the list ofarguments. For case 13, the comparison value is WEOF. For case 14, thecomparison value can be −2, or −1, or a value unambiguously determinedby the list of arguments.

There are several calling contexts which will meet the requirementslisted above:

-   -   a. A conditional control-flow test (if, while, for, switch, or        logical operator) which explicitly or implicitly tests the        returned value against the appropriate comparison value.    -   b. Assignment of the returned value to some object, after which        the first conditional control-flow test is a test that matches        the preceding context (#1).

This determination of proper calling context can in one exemplaryimplementation also be made available for user-written functions byproviding to user programs a macro such as _(——)CALLED_LIKE(name).

If the function is called properly, then error returns are handlednormally, without incurring additional run-time overhead in the callingor called function. In Debug mode, if the function was not calledproperly, extra code is generated in the calling function such that afailure return causes an ss_unwind with a descriptive string argument Innon-Debug mode, in all cases where execution can continue withoutcausing fetch-or-store errors, then execution continues withoutinterruption; otherwise a fatal diagnostic is produced at compile-time.The cases where a fatal diagnostic is produced in non-Debug mode arespecified below:

-   -   a. boolean (non-zero is success): none    -   b. null is failure: getenv. (Note that FILE* pointer parameters        are required to have the “indirectable” attribute in CSAFE mode,        so passing “maybe-indirectable” FILE* variables will be        diagnosed at compile time. Similarly, pointer returns from        allocation and searching functions do not demand immediate        null-testing, because the “maybe-indirectable” attribute will        require null-testing before later indirecting.)    -   c. SIG_ERR is failure: none    -   d. zero is success: atexit (Note: most I/O failures may produce        erroneous results but do not cause fetch-or-store errors.)    -   e. EOF is failure: none (Note: most I/O failures may produce        erroneous results but do not cause fetch-or-store errors.)    -   f negative is failure: none (Note: most I/O failures may produce        erroneous results but do not cause fetch-or-store errors.)    -   g. number of items transmitted: snprintf, sprintf, vsprintf        (Note: most I/O failures may produce erroneous results but do        not cause fetch-or-store errors.)    -   h. nonnegative and less than n: none (Note: most I/O failures        may produce erroneous results but do not cause fetch-or-store        errors.)    -   i. negative one is failure: mktime    -   j. high-low-equal: none    -   k. greater than n is failure: strxfrm, wcsxfrm    -   l. [reserved—no L]    -   m. zero is failure: strftime, wcsftime    -   n. WEOF is failure: none    -   o. minus two through n:: none        Compile-Time Diagnosis [et]

Many of the situations labeled as “undefined behavior” are capable ofdiagnosis by the compiler. In the methods presented here, the casesidentified by the code “ct” in column one result in the production of afatal diagnostic message by the Safe Secure Compiler 23. Furthermore,production of a fatal diagnostic message prevents the Safe SecureCompiler 23 from producing a translated file.

The C standard defines a diagnostic message as follows: “3.10 diagnosticmessage: message belonging to an implementation-defined subset of theimplementation's message output”. The C standard places this requirementon the #error preprocessor directive [ISO/IEC 9899 4 para 3]: “Theimplementation shall not successfully translate a preprocessingtranslation unit containing a #error preprocessing directive unless itis part of a group skipped by conditional inclusion.” In other words, a“fatal diagnostic” is a diagnostic message which has an effect as if itwere produced by a #error preprocessing directive.

The SSC 23 can issue a fatal diagnostic if any of the followingconditions occur in a C++ program: an object has incomplete type, itsaddress is taken, and the complete type is a class that contains anoperator&( ); the implementation-defined limit on template instantiationdepth is exceeded; flowing off the end of a function-try-block (orreturn with no value) in a value-producing function; declarations ordefinitions or template specializations are added to namespace std, ornames are declared or defined in a context where it is reserved (unlessotherwise specified in ISO/IEC 14882); instantiating a Standard Librarycontainer with an auto_ptr; the basic_filebuf traits::pos_type is notfops<traits::state_type>.

The methods shown in this section will eliminate the following undefinedbehaviors:

SSM# C-Std# Description ct c6.5.2.2 For a call to a function without afunction prototype in scope where the function is defined with afunction prototype, . . . ct c6.5.2.2 . . . either the prototype endswith an ellipsis or the types of the arguments after promotion are notcompatible with the types of the parameters ct c6.10.6 A non-STDC#pragma preprocessing directive that is documented as causingtranslation failure or some other form of undefined behavior isencountered ct c6.5.2.2 For a call to a function without a functionprototype in scope where the function is not defined with a functionprototype, the types of the arguments after promotion are not compatiblewith those of the parameters after promotion ct c6.5.2.2 For a call to afunction without a function prototype in scope, the number of argumentsdoes not equal the number of parameters ct c6.5.2.2, c6.5.15, An attemptis made to modify the result of a function call, a conditional c6.5.16,c6.5.17 operator, an assignment operator, or a comma operator, or toaccess it after the next sequence point ct c7.1.2 A file with the samename as one of the standard headers, not provided as part of theimplementation, is placed in any of the standard places that aresearched for included source files ct c7.1.2 A function, object, type,or macro that is specified as being declared or defined by some standardheader is used before any header that declares or defines it is includedct c7.1.2 A standard header is included while a macro is defined withthe same name as a keyword ct c7.1.2 The program attempts to declare alibrary function itself, rather than via a standard header, but thedeclaration does not have external linkage ct c7.1.3 The programdeclares or defines a reserved identifier, other than as allowed by7.1.4 ct c7.1.3 The program removes the definition of a macro whose namebegins with an underscore and either an uppercase letter or anotherunderscore ct c7.12 A macro definition of math_errhandling is suppressedor the program defines an identifier with the name math_errhandling ctc7.13 A macro definition of setjmp is suppressed in order to access anactual function, or the program defines an external identifier with thename setjmp ct c7.13.2.1 An invocation of the setjmp macro occurs otherthan in an allowed context ct c7.14.1.1 The program specifies an invalidpointer to a signal handler function ct c7.15, c7.15.1.1, A functionwith a variable number of arguments attempts to access its c7.15.1.4varying arguments other than through a properly declared and initializedva_list object, or before the va_start macro is invoked ct c7.15.1 Amacro definition of va_start, va_arg, va_copy, or va_end is suppressedin order to access an actual function, or the program defines anexternal identifier with the name va_copy or va_end ct c7.15.1,c7.15.1.2, The va_start or va_copy macro is invoked without acorresponding c7.15.1.3, invocation of the va_end macro in the samefunction, or vice versa c7.15.1.4 ct c7.15.1.1 The type parameter to theva_arg macro is not such that a pointer to an object of that type can beobtained simply by postfixing a* ct c7.15.1.4 The parameter parmN of ava_start macro is declared with the register storage class, with afunction or array type, or with a type that is not compatible with thetype that results after application of the default argument promotionsct c7.2 The macro definition of assert is suppressed in order to accessan actual function ct c7.5 A macro definition of errno is suppressed inorder to access an actual object, or the program defines an identifierwith the name errno SSM# C++-Std# Description ct 5.3 para 4 Object hasincomplete type, its address is taken, and the complete type is a classthat contains an operator&( ) ct 14.7.1 para 14 Exceeding animplementation-defined limit on template instantiation depth. ct 15.3para 16 Flowing off the end of a function-try-block (or return with novalue), in a value-returning function. ct 17.4.3.1 para 1 Addingdeclarations or definitions to namespace std unless otherwise specifiedct 17.4.3.1 para 1 Adding template specializations to namespace stdexcept as permitted ct 17.4.3.1 para 3 Declaring or defining a name in acontext where it is reserved (except where permitted) ct 20.4.5 para 3Instantiating a Standard Library container with an auto ptr ct 27.8.1.1para 4 Basic_filebuf traits::pos_type is not fpos<traits::state_type>Big Safe Pointers [bsafe]

This section presents an alternative to the compile-time-safe (“CSAFE”)pointers defined in the sections “States of objects [stat]” and “Safepointers [buf]”. In this alternative, all pointers are implemented as“big-safe pointers” (or “BSAFE” pointers) using a struct containingthree ordinary pointers (each represented as a pointer to an underlyingtype T). The methods shown in this section provide an alternativemechanism to address the undefined behaviors that are listed above inthe section “Safe pointers [buf]”.

In one specific implementation, the big-safe-pointer mechanism isachieved by transforming the C or C++ source program into a C++ programin which each big-safe pointer is implemented as a template struct:

template <class T> struct bsafe_ptr {T* ptr; T* lo; T* hi;};

Thus, every big-safe pointer will include low and high boundsinformation.

In an alternative embodiment, the high-bound information is representedas a Tsize-adjusted field. The Bound is defined as the Tsize divided bythe size of the type T to which the pointer is pointing. TheTsize-adjusted is the Tsize minus the size of the type T, i.e. thenumber of bytes in the array between the address of the first object oftype T and the last object of type T. If there is only one element inthe array, the Tsize-adjusted is zero.

In order to make a copy of a bsafe_ptr, we provide a clone(T* p) member:

bsafe_ptr<T> clone (T*p) {   bsafe_ptr<T>* ret = new bsafe_ptr<T>(p,lo,hi);   if (Debug && p > hi+1) {    delete ret;   ss_unwind(“bsafe_ptr out of range: clone \n”);   }   ret->ptr=p;ret->lo=lo; ret->hi=hi;   return *ret;  }

Since the initial target language is the intersection of C and C++, wewant to map the semantics of big-safe-pointers into a macro-compatiblesyntax:

#define LO_OF(p) ((p).clone((p).lo)) #define HI_OF(p) ((p).clone((p).hi)#define END_OF(p) ((p).clone((p)+BOUND OF(p))) #defineBOUND_OF(p) (TSIZE_OF(p)/sizeof((*p))) #define TSIZE_OF(p) ((size t)((p).ts) + sizeof(*(p)))

In other words, END_OF(p) is a bsafe pointer with the same Lo and Hivalues as p and containing the “one-too-far” address as its current ptrvalue. Similarly, LO_OF(p) is a bsafe pointer with the same Lo and Hivalues as p and containing p.lo as its current ptr value. TheBOUND_OF(p) is an integer designating the number of elements in thearray that extends from LO_OF(p) to HI_OF(p). The TSIZE_OF(p) (“targetsize of p”) is the number of bytes in the storage accessed through p.

We define the Lo-Hi information, or Lo-Hi bounds, as the informationembodied in the lo and hi fields.

A pointer value that designates an object in an array includes thebounding addresses of the array. Assigning a pointer value to a pointerobject preserves the lo, hi, and ptr members. Creating a pointer via thebig-safe version of malloc(N) produces a bsafe_ptr containing the ptraddress of the new storage, a lo equal to ptr, and a hi of N/sizeof(T).Casting a bsafe_ptr, for example from char* to T*, converts ptr and loto T* values; if ptr or lo are not properly aligned, an ss_unwind israised.

Pointer arithmetic (ptr+n, ptr−n, ptr−ptr, ptr[n]) and fetch-and-storeindirection operators (explicitly via “star” or implicitly in the 1value use of subscript) are checked and diagnosed according to the rulesas described in section “Safe pointers [buf]”, with the obviousinclusion of run-time checking against the values store in thebig-safe-pointer.

Note that the first member of a bsafe_ptr is the pointer value ptr. Thisis intentional and required; any non-BSAFE code which refers to absafe_ptr as an ordinary pointer will properly address the pointervalue.

In the big-safe-pointer alternative, all external pointers havebsafe_ptr representation. In particular, any system-defined externalpointers (such as environ) have bsafe_ptr representation. (The cost isonly two extra words per external pointer.)

There are a few application niches which might conceivably use onlybig-safe pointers, such as the training of programmers, the creation ofuser-provided callback functions, the production of specialized“one-off” prototypes, etc. All are areas that might be willing to tradesome time and space for greatly increased reliability. However, mostapplication domains are using C and C++because of superior intrinsicefficiency, and the overheads of big-safe pointers would be commerciallyunsupportable; this favors the compile-time-safe pointer methods asdescribed earlier.

Note that the printf/scanf functions use pointer arguments for the % sand % p formats. Therefore, although the old “unsafe” versions can becalled via a “wrapper” in the CSAFE mode, the wrapper must indicate by astate flag that % p input produces a “not-indirectable” pointer in theCSAFE mode. The fully bounds-checked versions can be provided in BSAFEmode

Including the big-safe-pointer alternative, the Safe Secure method hasdefined four modes of code generation: Debug BSAFE, Debug CSAFE,non-Debug BSAFE, and non-Debug CSAFE. A further alternative is to reducethe modes to two: Debug BSAFE and non-Debug CSAFE.

Implementing the SSBDF Using Name-Mangling [mangl]

One non-limiting method for implementing the SSBDF 26 makes use of thename-mangling facilities of C++, employing appropriate encodings in theobject-file representation to convey the bounds information for eachfetch-and-store variable in each function's calling sequence. Theparameter type can be encoded into the apparent classname of the pointerargument:

_(——)csafe_ptr_B1 Bound = 1 _(——)csafe_ptr_Ba2 Bound = int arg#2_(——)csafe_ptr_L5 Length = 5 _(——)csafe_ptr_La7 Length = int arg#7_(——)csafe_ptr_T9 Tsize = 9 _(——)csafe_ptr_Ta_11 Tsize = int arg#11_(——)csafe_ptr_A3 Tsize-adjusted = 3 _(——)csafe_ptr_Aa4 Tsize-adjusted =int arg#4 _(——)csafe_ptr_Ae10Identifier Tsize-adjusted = externalIdentifier of 10 characters _(——)csafe_ptr_Oa1 Lo = compatible-type ptrarg#1 _(——)csafe_ptr_Ha2 Hi = compatible-type ptr arg#2_(——)csafe_ptr_Ea3 End = compatible-type ptr arg#3 _(——)csafe_ptr_Oa1Ha2Lo = compatible-type ptr arg#1, Hi = compatible-type ptr arg#2_(——)csafe_ptr_I Indirectable _(——)csafe_ptr_QI Maybe-indirectable =indirectable or null _(——)csafe_ptr_NI Not-Indirectable_(——)csafe_ptr_NT Null-Terminated (with no other bounds info)_(——)csafe_ptr_NTTa1 Null-Terminated, Tsize = int arg#1

Using this system, the object code for memcpy would embody encodingssuch as these:

_(——)csafe_ptr_Ta1<void> memcpy(_(——)csafe_ptr_Ta1<void> s1,_(——)csafe_ptr_Ta1<void> s2, size_t n);

Parameters which are not pointers may be involved in fetch-or-storeexpressions in the called function, so a similar encoding is providedfor non-pointers:

_(——)csafe_n_Te2Id This integer parameter is the Tsize of the externalarray named “Id”. _(——)csafe_n_Ie1A This integer parameter isindirectable (i.e. usable as subscript) for the external array named“A”. _(——)csafe_n_Be3buf This integer parameter is the bound of theexternal array named “buf”. _(——)csafe_n_Le3str This integer parameteris the length of the external array named “str”.

Sometimes within a Source Program 107 an integer parameter is usedwithin the called function to specify the bounds, or subscript, forseveral different external arrays; the SSSA 35 knows which arrays thoseare from examination of the code in the called function. Rather thanencoding all those array names into the parameter's augmented-type, thearray with the smallest bound should be chosen; if two or more have thissame bound, choose the shortest name; if two ore more names have thesame length, choose the lexicographically smallest name. Here is anexample that illustrates the intended usage:

File 1: extern int a[ ]; void f(int k) {   a[k] = 1; }

File 2: int a[64] = {0}; int main( ) {   int j;   for (j = 0; j < 64;++j)     f(j); }

The augmented signature of the function f is as follows:

void f(_(——)csafe_n_Ie1a<int>)

This presents a Requirement for the invocation of f in File 2, namely,that the argument must be suitable for use as a subscript on array a,and informs the main program that the variable j is being used forfetch-or-store access to a. The main program must determine the range ofvalues for j and verify that j is suitable as a subscript on array a.

Since the names of these “helper” classes are intended only forconsumption by the Safe Secure Compiler 23 itself, there is no need forhuman-readable names in this context. In the preferred implementation,an alternative encoding is produced by reducing the length of the namesof the “_csafe” classes while avoiding collision withimplementation-defined names in the implementer's namespace. The parsingof the class names as part of a mangled name requires no lookahead oradded terminators. When integers are permitted in the name, asingle-digit integer is encoded as-is, and an N-digit integer isprefixed by N−1 underscore characters. When an identifier is encoded, itis prefixed by the N-digit integer designating the length of theidentifier (without any leading underscore characters).

Notating an attribute as a post-condition (shown as POST earlier) isachieved by adding a marker such as ‘P’ in the augmented name-manglingmethod:

int swprintf(_csafe_ptr_NTBa1PLa0<wchar_t>restrict s,   size_t n ,  _csafe_ptr_NT<const wchar_t>restrict format, ...);

Note that in the Guarantees, the returned value is indicated as“argument number zero”, with digit zero.

In CSAFE mode, any pointer argument can have the “not-indirectable”attribute. This attribute is the default attribute for pointerparameters. This attribute is explicitly documented via the templatetype_csafe_ptr_NI<T> (“csafe pointer, not-indirectable”), or more simplyas an ordinary T* pointer.

Making Changes to Incorporate the Safer C library [libchanges]

The components and methods embodied in the SSC 23 and SSL 28 can be usedto convert existing C and C++ programs to make use of the Safer Clibrary referred to above in “Secure library [slib]”.

In one alternative, the methods described in “Dynamic monitoring ofallocated storage [dyna]” are not used in the compiler which willcompile and execute the C or C++ program. In this alternative, allinformation needed to prevent undefined behavior (such as array-boundsinformation) must be verified by the SSC 23 and SSL 28 at compile-timeand link-time respectively, otherwise a fatal diagnostic is produced.For each (“non-deprecated”) function defined in the Safer C library(such as strcpy_s), there is a corresponding function that lacks someindication of the bounds data of the target (such as strcpy); call thatthe “corresponding deprecated function”. The set of all thecorresponding deprecated functions constitutes the “deprecatedfunctions”. For each invocation of a deprecated function in the programbeing compiled, the bounds-data Requirements are well-known in thecurrent art, as illustrated in the table at [0129] above. If the SSC 23employing the methods given above is unable to determine a correspondingbounds-data Guarantee, then the methods above specify that a fataldiagnostic is issued. Otherwise, the source code invocation isre-written by the SSC 23 to an invocation of the correspondingnon-deprecated function, in which the bounds-data Guarantee isexplicitly passed as an argument. If the source-code context tests thereturned value from the deprecated function, then the SSC 23 consultsthe table given above in “Function invocation patterns [invoc]”, torewrite the success-or-fail test into a test against the “errno_t”returned value from the corresponding non-deprecated function.

In a second alternative, the methods described in “Dynamic monitoring ofallocated storage [dyna]” are used in the compiler which will compileand execute the C or C++ program. In this alternative, even if allarray-bounds information has not been verified by the SSC 23 and SSL 28at compile-time and link-time respectively, the resulting executableprogram will still produce no undefined behaviors, because of thedynamic-monitoring mechanisms. If the SSC 23 employing the methods givenabove is unable to determine a corresponding bounds-data Guarantee, thenthe source code invocation is not re-written by the SSC 23. Theinvocation of the deprecated function (such as strcpy) remains in thesource code. In this alternative, the user-callable deprecated functionsare provided in specially-programmed versions, and the uncheckedlow-level equivalents (such as _unchecked_strcpy) are also provided, asindicated in the prior art cited above in “Dynamic monitoring ofallocated storage [dyna]”. If the invocation of the deprecated functionis re-written into an invocation of the corresponding non-deprecatedfunction, and f the source-code context tests the returned value fromthe deprecated function, then the SSC 23 consults the table given abovein “Function invocation patterns [invoc]”, to rewrite thesuccess-or-fail test into a test against the “ernno_t” returned valuefrom the corresponding non-deprecated function.

Providing Optimizations for the Safer C Library [liboptim]

The components and methods embodied in the SSC 23 and SSL 28 can also beused to optimize the execution of C and C++ programs that make use ofthe Safer C library referred to above in “Secure library [slib]”.

In one alternative, the methods described in “Dynamic monitoring ofallocated storage [dyna]” are not used in the compiler which willcompile and execute the C or C++ program. For each invocation of anon-deprecated function defined in the Safer C library (such asstrcpy_s), the SSC 23 may be able to determine at compile time that allthe Requirements of that non-deprecated function are met by Guaranteesin the source program. In such cases, the compiler can implement theinvocation by an invocation of the corresponding deprecated (moreefficient) function. The returned value is known at compile the success(zero) value; any non-empty code along the failure (nonzero) branch canbe eliminated as dead code.

In a second alternative, the methods described in “Dynamic monitoring ofallocated storage [dyna]” are used in the compiler which will compileand execute the C or C++ program. For each invocation of anon-deprecated function defined in the Safer C library (such asstrcpy_s), the SSC 23 may be able to determine at compile time that allthe Requirements of that non-deprecated function are met by Guaranteesin the source program. In such cases, the compiler can implement theinvocation by an invocation of the corresponding unchecked low-levelequivalent function (such as _unchecked_strcpy). The returned value isknown at compile time to be the success (zero) value; any non-empty codealong the failure (non-zero) branch of the test can be eliminated asdead code.

All documents referred to above are incorporated herein by reference.

While the technology herein has been described in connection withexemplary illustrative non-limiting embodiments, the invention i not tobe limited by the disclosure. The invention is intended to be defined bythe claims and to cover all corresponding and equivalent arrangementswhether or not specifically disclosed herein.

1. A software development method for use in a software developmentsystem comprising a combination of hardware and software including astorage device and a compiler, said method comprising: said compilerreceiving, from said storage device, at least one C or C++ input sourcefile embodying the features defined in the full ISO C90 standard and/orthe full ISO C99 standard and/or the full ISO C++ standard; and saidcompiler compiling said input source file into an executable objectfile, wherein said compiling automatically identifies and/or eliminatessubstantially all undefined behaviors of said input source file, andwherein said compiling includes generating object code which is freefrom predetermined designated sets of undefined behaviors includingbuffer overflow and null pointer indirection, and incorporating at leastthree methods used in producing said object code, selected from thefollowing group: (a) in _Sat logic where a subscript or pointer N doesnot exceed a Hi value, a generated assembler code uses assemblerconditional instructions including any one or more of Load N, Cmp Hi, anLoad Hi if Greater; (b) when a processor supports only a _Sat logic thatsaturates at a UINT_MAX value (P), the generated assembler saturates atan arbitrary Bound using an “Add-Sat” instruction (add with saturationat P) including any one or more of Load N, Add-Sat (P-Bound), Subtract(P-Bound); (c) when a Bound is a power of two, then a _Modwrap logic isprovided by a bitwise-and including an option to be evaluated in codeoptimization of allocating extra elements in an array to make its actualBound be a next higher power of two; (d) when the Bound is 255 or65,535, the generated assembler code maintains a subscript value N as aone-byte or two-byte value within a larger value, using one-byte ortwo-byte instructions, which will act as if every store of N werebitwise-anded with 0xFF or 0xFFFF before each store; and (e)implementing _Zerobound logic using conditional assembler instructionsincluding any one or more of Load P into reg A, Cmp Bound (producing azero or nonzero value in reg B), Load if B is nonzero *A into B (leavingthe zero result of comparison as the result value of the _Zeroboundlogic).
 2. The method of claim 1, further comprising one or both of:said compiler re-writing said input source file into a source file whichinvokes non-deprecated functions in a Safer C library; and said compilertransforming invocations of non-deprecated functions in the Safer Clibrary into invocations of corresponding more-efficient functions.
 3. Asafe secure software development system, comprising: a storage devicearranged to store a C or C++ input source file meeting full ISO C90 andC99 standards and/or full ISO C++ standard; and a compiler arranged tocompile said input source file into an executable object file, whereinsaid complier automatically identifies and/or eliminates substantiallyall undefined behaviors of said input source file, and wherein saidcompiler is arranged to perform a safe secure compilation which includessafe secure code generation of the object code which is free fromdesignated sets of undefined behaviors including “buffer overflow” and“null pointer indirection”, and incorporating at least three methodsused in producing said object code, selected from the following group:(a) in _Sat logic where a subscript or pointer N does not exceed a Hivalue, a generated assembler code uses assembler conditionalinstructions including any one or more of Load N, Cmp Hi, an Load Hi ifGreater; (b) when a processor supports only a _Sat logic that saturatesat a UINT_MAX value (P), the generated assembler saturates at anarbitrary Bound using an “Add-Sat” instruction (add with saturation atP) including any one or more of Load N, Add-Sat (P-Bound), Subtract(P-Bound); (c) when a Bound is a power of two, then a _Modwrap logic isprovided by a bitwise-and including an option to be evaluated in codeoptimization of allocating extra elements in an array to make its actualBound be a next higher power of two; (d) when the Bound is 255 or65,535, the generated assembler code maintains a subscript value N as aone-byte or two-byte value within a larger value, using one-byte ortwo-byte instructions, which will act as if every store of N werebitwise-anded with 0xFF or 0xFFFF before each store; and (e)implementing _Zerobound logic using conditional assembler instructionsincluding any one or more of Load P into reg A, Cmp Bound (producing azero or nonzero value in reg B), Load if B is nonzero *A into B (leavingthe zero result of comparison as the result value of the Zeroboundlogic).
 4. The system of claim 3 wherein said compiler is arranged toperform one or both of: re-write said input source file into a sourcefile which invokes non-deprecated functions in a Safer C library; andtransform invocations of non-deprecated functions in the Safer C libraryinto invocations of corresponding more-efficient functions.